Cain Manor

From a command window run…

regsvr32 mshtml.dll
regsvr32 shdocvw.dll -i
regsvr32 shell32.dll -i

After each command, you’ll get a pop-up window saying “xxx was registered”
I support a lot of W2K boxes :(

osql -E- Login with your Windows credential

to change your authentication mode to Mixed Mode (meaning you can use both local password such as sa, and Windows Credentials), change…

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\LoginMode from 1 (default) to 2(mixed).

Now that you have mixed, mode you can change the sa password..

osql -E

sp_password NULL,”<new-password>”,sa

go

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 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’ »