Cain Manor

For those savvy in the ways of Unix and maybe even VMware, here is what you need to do…

vmkfstools -i /<source directory>/<VM name>.vmdk /<destination directory>/<VM name>.vmdk
cp /<source directory>/<VM name>.nvram /<destination directory>/<VM name>.nvram
cp /<source directory>/<VM name>.vmx /<destination directory>/<VM name>.vmx

Edit beyond01.nvram and change the swap volume path - AKA sched.swap.derivedName
Register - vmware-cmd register -s /vmfs/volumes/OS_Store/beyond01/beyond01.vmx

Error message about msg.uuid.moved. Use Keep if you are just moving.

Now for the long answer
Continue reading ‘Moving a .VMKD in VMware ESX 3.5’ »

Tools -> Account Settings

Under the e-mail tab select “microsoft exchange” and click change

More settings - advanced tab

click add - add the name of the new mailbox.

I just got Office 2007 installed.  On the very top is a yellow bar asking me to “Click here to enable Instant Search.”  This is Microsoft’s attempt to get me to install their intrusive Desktop Search, and clicking the bar takes you to the download page for that product.    It’s ugly and unwanted and it took some time to figure out how to disable it.  To disable…

Tools -> Options -> Other -> Advanced Options -> remove the check box for “Show prompts to enable Instant Search”.

An option to either install or remove would have been a lot easier.

To use this, just copy it to you computer, and rename it something.vbs. (Thanks to Darin for pointing that out.)

Const MY_COMPUTER = &H11&
Set objNetwork = CreateObject("Wscript.Network")
objComputerName = objNetwork.ComputerName
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(MY_COMPUTER)
Set objFolderItem = objFolder.Self
objFolderItem.Name = objComputerName

I had an SE contact me about services.exe using excessive memory on some of his boxes (~130MB.) As he was worried about this (and he had a ticket), so was I. I started with the semi-handy Process Explorer from Microsoft. I’ve been spoiled by the nifty things you can do with UNIX (lsof for instance), but I couldn’t get to the bottom of what was taking up so much memory. After 90 minutes on the phone with Microsoft Platinum support, it appears that (drum roll please) the event logs were taking up the memory. We backed up and then cleared the event logs, and the memory went down to a more manageable, and expected, size (~8MB.) Apparently, the event logs are cached on startup (and kept in memory as they grow?). However, this isn’t that big of a deal as services.exe is one of the first processes that gives back memory to a memory constrained system

The support guy from Microsoft went away for a few minutes and found this out from talking to one of his peers. I’m no closer to figuring out how to troubleshoot memory processes on a deeper level. His only suggestion was to get a crash dump from the server and run windbg against it. On a Linux box, you can just run lsof, or dtrace or… well, you get the idea.

We had a major issue where Symantec Anti-Virus would not update some (but not all) 64 bit clients. To make a long story short, it ended up being corrupt files that had previously been downloaded by Live Update, and lived in the LiveUpdate directory on the server. To clear up the problem we had to…

Continue reading ‘A fix for multiple Symantec AntiVirus x64 clients not updating correctly’ »