CommsCentral

Advanced setting preference pane add-in for OS X

Thu, 17 Dec 2009 21:48:09 +1000

Hi All,

So a few weeks back I found a really useful application for mac OS X that allows setting of some advanced settings in OS X.
Now I can already hear the hardcore command line guys, saying, but you can do this at a command line level. yes I know! However this makes it easy, knows what the default was (incase you want to go back) but also tells you what advanced settings there are!

The program is called Secrets and its a preferences plugin. The site is http://secrets.blacktree.com/ and they also have a really handly list of all the secrets, plus the command line commands to set them! Which is almost as handy as the program!

I've certainly found it useful for a few bits and pieces!

Enjoy!

Caveman...

Changing ESX virtual centre server when original virtual host no longer available

Tue, 14 Jul 2009 16:53:04 +1000

Just a quick post today but I wanted to share something useful I discovered.

I've got a vmware esx server that is setup and is managed using virtual centre. Due to hardware limitations we have virtual centre running inside a vmware on the esx server.

I know this isn't best practice, however it is a supported configuration by vmware.
Recently we had a power outage that rebooted the server and the vm running virtual centre wasn't setup to start automatically so the virtual centre server didn't come back up.
This virtual centre server also handles the licensing for the esx host. Due to there being no licensing server available, after the 14 day grace period, esx wouldn't allow any new vm's to be started as it didn't have a license.
This presented me with a problem, I needed to start up the virtual centre server to fix the licensing issue, however esx didn't have any licenses to start the vm up........ URHHHHHHHHHHHHH!!!!!!!!!!!

I figured the only solution would be to bring up another server with virtual centre installed and point the esx server at that so it would have a license and then allow me to boot up the vm before repointing the esx host back to its vm virtual centre.

However there is a problem a I quickly discovered, ESX won't let you remove a virtual centre from managing it, unless it can contact that virtual centre server to say "goodbye".
You can add the ESX host into the other virtual centre however it quickly disconnects and you can't manage it at all.

After a bit of head scratching I found a solution.
1. ssh to your esx host.

2. Edit your license.cfg file in /etc/vmware/license.cfg (vi /etc/vmware/license.cfg as root will do it)

3. Here we have 2 possible solutions. 1, empty the file or 2, modify the line that reads like SERVER=27000@192.168.1.10 to something else.
I've found that solution 2 doesn't seem to work, I found solution 1 worked for me, but from the vmware docs option 2 should work.

4. Then run /sbin/service mgmt-vmware restart

Your ESX host will now reboot and if you went option 1 at step three you will be able to add the ESX host back into another virtual centre server.

Problem solved!...

Redirecting Documents and Settings and Local Settings on a Citrix / terminal server environment

Mon, 02 Mar 2009 22:53:30 +1000

Hi All,

As most of my readers probably have gathered I work in IT for a company who supports environments for small to medium business.
Recently I've been working in a team to build a citrix server farm for around 300 users.

In this project we had a particular application that does a local install into Local Settings in the users profile and these local settings needed to be saved and roamed from one server to another.
We were using windows roaming profiles due to their ease of support and deployment into an exiting environment. How this posed a specific problem, by default windows roaming profiles doesn't roam local settings or any of the folders contained within it.

I discovered two possible solutions to this problem.

Solution 1:
Was to redirect the whole Documents and Settings folder to another location such as on a file server or a mapped network drive (if UNC paths weren't supported).
This can be done with the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory
The default value of this key is %SYSTEMDRIVE%\Documents and Settings however this can be change to anything. Like D:\Documents and Settings or changed to a network UNC path such as \\mainFileServer\tsprofiles which is what I would have done for our citrix farm.

This will cause windows to use that path for its documents and settings folder. This would also remove the need to setup windows roaming profiles for the terminal server farm, as each server would have its documents and settings pointed to the same file server share.
It should also be noted that using this doesn't increase logon times, infact it will reduce them as it prevents the users profile from having to be downloaded from the profile server and cached locally on the terminal server itself until logoff, at which point it gets packed up and set back to the profile server.
However any file that is saved to the users profile will take longer, as instead of writing to a local disk, we'd be writing to a network share and we'd have all the network overhead to deal with.
It would also result in a lot of open files on the profile server, for example if word, and outlook where open, you'd have any outlook pst files open and words normal.dot amount other files. It becomes apparent that this number could quickly rack up.

So why is this a worry? When I file is opened via a remote share, this whole file has be able to be loaded into something called kernel memory by the kernel so the data can be fed off to the network stack. On a 32bit system the maximum amount of kernel memory possible is 2GB (yes I know 32bit OS's support 4GB of memory, however that's not native support and splits user land and kernel land apart, but this is outside the scope of this article).
If you happen to run out of kernel memory you will start getting unable to open file errors when trying to open a file over a network share or on the system itself, if the situation becomes bad enough you will find that core services like group policy processing won't be able to run and the server will lock up and have to be rebooted or have the open files closed (if that's possible).

If the 2GB max is not enough kernel memory the only option will be to go for a 64bit operating system. Current Microsoft 64bit operating systems can support up to 8 terabytes kernel memory, although in theory 64bit can address up to 16 exabytes.
See http://support.microsoft.com/kb/294418 and the table under the heading System PTEs for more information.

Solution 2:
Solution 2 certainly wins under the simple heading!
Clearing the value of the key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs causes windows roaming profiles to copy the local settings folder and the folders under them, just like any other folder in the users profile!
The default value of this key is: Local Settings; Temporary Internet Files;History;Temp

In my case I just cleared this whole key, as I wanted all the settings to copy over, however some folders could still be left in here.
I also believe it would be possible to use this key to exclude certain folders inside the profile itself from being roamed and saved back to the profile server. Which would be handy if you were dealing with an application that had a really large and unneeded amount of data in a folder, which didn't need to be saved.

This solution has a disadvantage in the fact that if the local settings folder is large it will increase logon and logoff times just because of the amount of data that has to be downloaded and upload. However in my case the profile server didn't have the resources to support all the open files from solution 1, so this was the only decent option left.

I have included a paste and a link to an group policy template I made that will clear this key for any user who has the policy applied and make local settings roam at the end of this post.

Have fun!

Caveman

---------START RoamingLocalSettings.ADM-------------
CLASS USER

CATEGORY !!RoamingProfiles
POLICY "Enable local settings in roaming profiles"
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
VALUENAME ExcludeProfileDirs
VALUEON ""
VALUEOFF "Local Settings;Temporary Internet Files;History;Temp"
END POLICY

END CATEGORY

[strings]
RoamingProfiles="Enable local settings in roaming profiles"
---------END RoamingLocalSettings.ADM-------------

Download ADM file HERE
...

Microsoft RDP (remote desktop protocol) client options and tricks

Sun, 01 Feb 2009 21:12:29 +1000

Today's topic is RDP, microsoft's remote desktop protocol.
Any windows server guy will know well about RDP and will probably use it on a day to day bases to access servers.

RDP is a good implementation of a remote desktop program unlike VNC which is very laggy and slow. RDP still works well even on slow links, this is mainly made possible by actions being run in a virtual display space which are then sent back to the remote host, this gives rdp the feel that it quicker. It also doesn't bother tracking the mouse of the remote host and just inputs the mouse location and clicks to the best of my understanding.
But enough on how it works, that's for another topic. Today's topic is about the cool options the RDP client has.

Please note: This is written for RDP 6.0 and above. Version 6 comes with vista and can be downloaded for server 2003 and xp. Service pack 3 for XP also comes with the new verison.
Some of the below commands are supported with the older 5.x series

Clipboard copy, I work with dual monitors and work and I find that I regularly want to be able to copy a piece of text from my desktop machine to another machine via RDP.
To enable clipboard start the RDP client, go to options and then select the Local Resources tab.
Down the bottom you'll see group called Local Devices and Resources, on the left of this group there is a clipboard option.
NOTE: supported in version 6.x only

Drive mapping. This is one I've found a lot of people may not know! Its possible to share a drive on your machine into a remote machine over an RDP connection. This is very very useful on corporate networks where you need to get a file to a server and the only opened port is the RDP port (3389).
To enable drive mapping go to options, then Local Resources then down the bottom click the more button, then tick drives or select all of them. Also note that RDP 6.x will detect drives you connect later to your machine and dynamically map then into the system your remoted onto, which ROCKS!
Also note in version 5.x of the RDP client the drives checkbox can be found just under Local Resources.

For slow links. For those forced to have to use RDP over a slow line (such a 10KB/s link) there are a few options that can be enabled to really make an improvement. Infact I've found RDP at 10KB/s to be more than usable!
The first option to enable is 256bit colours by going to options, then display and setting colours.
The next options you can enable to speed up performance are found under the experience tab in options.
Unticking all the options except for Bitmap caching (which you should leave enabled) will give you the least bandwidth usage possible.

Console. If you RDP to a single user licensed such as an XP or Vista desktop by default you will get what is called the console connection. When you connect to console via RDP you won't be able to access that same machine via is hardware display and keyboard. For example if I RDP to my XP desk machine from another machine, I won't be able to also use that same machine from my desk.
This also applies to windows servers, however by default windows 2003 server allows two NON console RDP connections.
Another cool feature of RDP console connections is if someone else is logged onto the console port it will prompt you if you want to force log them off (assuming you have rights to), where as on one of the other server 2003 rdp connections you will be told that the server is full.
This is very handy if your accessing the server/machine in an emergency and its ok to kick anyone else using the console off without using tsadmin to log their sessions off.
To start console mode in RDP, to go start run and type: mstsc /console
The /console flag forces RDP to load up in console mode.

RDP ports and connecting to RDP servers on different ports
The default RDP client port is TCP port 3389 and no other ports should be required.
The RDP server can be changed from port 3389 to another port, setting up the server is outside the scope of this article, however connecting to a different port isn't.
If you had a RDP server running on port 443 then in the RDP client you'd type the following: serverYouWantToConnecTo:PORT
So to connect to a server running on port 443 at the IP address 10.1.2.3 you'd put the following in: 10.1.2.3:443

Modifying your default RDP settings
The default RDP settings for the version 7 of the RDP client are obtained from the Default.rdp file. This is a hidden file which is located in your my documents folder.
Opening this file in notepad will allow you custom change your default RDP settings, some of which you can't change via the GUI (at least to my knowledge).
Microsoft have a list of these options and what they do at http://support.microsoft.com/kb/885187.

I found recently a useful little trick to force your RDP settings not to change.
I logon to a terminal server to get onto the network of one of the networks I admin and from that TS box I remote to other servers, on the TS box I don't want my secondary RDP sessions (from the ts box to another server) to go full screen as then it becomes a real pain to switch between stuff I have open on the TS box and the RDP session.
I modified the desktopwidth and desktopheight values in the Default.rdp, however I don't want these values to be able to change and I discovered if I ever did logon full screen to a server it would reset back to full screen as the default.
I got around this by simple marking the Default.rdp file as read only in windows permissions.
A easy little trick that makes my life so much simpler day to day!

Thats all the regular RDP options I use, I'd love to hear your feedback if there are some others which you find super useful!

Caveman

...

Logon to dual gtalk accounts

Tue, 30 Dec 2008 11:31:07 +1000

Today I found a very neat little trick today with the google gtalk client which allows you to logon to multiple gtalk accounts at the same time.

If you start the gtalk.exe with the /nomutex flag it will allow you to load multiple different instances of the program. Hence your able to logon to two (or more) gtalk accounts from the single machine while only having the one client installed once!!

In my case I just updated my start menu icon target to "C:\Program Files\Google\Google Talk\googletalk.exe" /startmenu /nomutex

Hats off to Google! Good work boys, smart design!

Caveman
...

Converting a SOE install into a VMware image

Wed, 24 Dec 2008 14:45:30 +1000

Like most companies we have a bunch of SOE (standard operating environment) that run on our various machines.

We currently seem to be having a lack of physical hardware onhand as test machines.
I figured the second best would be to create an ESX server machine and then just load a whole heap of SOE images into that and use those as our test hardware.
I know the hardware layer drives will be different, however its good for just being able to run through testing of applications and testing software deployments which is my part of the world.

Only one question remains, how do you get these SOEs into ESX?
Just installing via the ISO into vmware fails, as the SOE doesn't have the driver files for vmware ESX.
The best option is to use the free vmware converter.

The vmware converter will convert various version of vmware images into different types but more importantly it will convert physical hardware into vmdk's (vmware disk files) that can be loaded into esx.

To convert our SOE into ESX I did the following.
1. Image a laptop with the SOE (was one test machine we DID have!)
2. Install vmware converter
3. Select vmware converter to convert the local machine directly into my ESX server.

During doing this I discovered something about vmware converter which is really cool!

You can select a remote machine!! This means I can install vmware converter onto a server or desktop and then use that to convert laptops etc that I connect up to the network into vmdk's without having to install vmware converter on each one!

It should be noted that this obviously requires full admin access to the machine that your converting and full access to the ESX server to import the images.

I'm not sure when this remote feature was added to vmware converter, but I don't remember it being in previous versions.

Certainly very cool! And now I have all the SOE images on my virtual machine to mess around with.

Caveman
...