since we did a network overhaul (defined in detail shortly) 2 years ago, we have had zero incidents of malware/virus’/badware on any machines that we know of (i know i will probably walk into bedlam tomorrow morning after saying that ;). after a recent mailing list conversation, i thought i would share some stuff we have done in detail to help anyone else going about the same process. here we go.

the 30 thousand foot view is this:

  • we reformatted every workstation and every server in one weekend (yes, you read that correctly)
  • users given user only rights, no power users or administrators.
  • we leveraged ms gpo’s to hide the c drive, limit what type of files could be saved, and prevent applications from running unless specifically allowed (application whitelist), etc.
  • we utilized ms’s wsus to apply patches across the board, workstations and servers
  • we started using a gateway device that did web filtering and also implemented a squid proxy server with whitelists
  • a copy of advanced installer was purchased so we could create msi’s to push all software out via gpo’s (this is great for new versions of software, pulling back software, etc)
  • we used gpo’s to config the workstation so that it automatically logged into our terminal server farm via single sign on (sso), more or less creating a pseudo thin client out of cheap desktop machines

working motto’s:

  • if you want a user to do/not do something, don’t ask them. force them.
  • prevention is the best medicine


read more

after a lot of looking and quite a bit of testing and customization, i think i have finally found a replacement for adobe acrobat reader.

why replace acrobat reader? off the top of my head:

  1. security issues. everywhere. frequently.
  2. and hence because of the security issues, you have to patch often. very often. which requires time, testing, and a fair amount of good luck to not break *anything*.
  3. and lastly, i was interested in replacing adobe because of its tendency to crash, specifically in our AD environment (see this post for more details). its not often, but often enough that i get some calls

so here is what i did. i searched. a bunch. i of course found foxit, and i tested foxit pretty heavily. i like foxit, and it was very close to what i was looking for, but then i ran across tracker software’s pdf xchange viewer. not only was it small and fast like foxit, i could mod the heck out of it to get it to look the way i wanted, and it could modify pdf’s, all for free.

heres how i turned this:

into this:


read more

so you can probably guess from the title that we were having problems with some msi’s not being deployed correctly to “random” virtual servers. you can also probably guess by the quotes around random that it wasn’t random at all, and there was a very good reason. here are the details.

we use a msi creator called advanced installer (www.advancedinstaller.com) to create and deploy all of our applications to client workstations and servers.

what we noticed was that after trying to install a msi to a cluster of terminal servers, the msi was only getting installed correctly on a handful a machines. now, i say “machines”, but the interesting wrinkle was that all these machines are actually virtual, and they are spread across a vmware esx cluster.

when we would log onto the windows host to look at the logs and why the msi didn’t get installed, here is what we found:

so even though the clock on the OS was right (and we triple checked this), at logon when policies and gpo’s were being applied, the clock was wrong. in this picture, this error actually happend about 3 minutes before the picture was taken, even though it shows a time difference of almost 8 hours.

the one thing we uncovered was that every server that got the gpo and msi’s installed correctly were all located on one esx host. when we looked at the time settings in esx, we found that on the servers having problems, the esx hosts ntp service was stopped, or hadn’t been configured at all.

from there, it was pretty easy. we just went to every esx/esxi host and configured and enabled the ntp server, and viola, the gpo’s and msi’s installed without a hitch!


read more

i initially was just going to post a fix i had found (via google) to resolve a rediculous problem that adobe acrobat reader 9.x has in it. after reviewing my fix and seeing how ugly the code/logic was, i ended up rewriting the script.

so there are two lessons in this post
1.    adobe will never get their act together (at least with acrobat reader 9)

2.    the fear of peer code review is good, and it forced me to reevaluate some sloppy scripts that “just work”, but do it in a half-baked manor
so here we go, adobe acrobat reader 9.x and its issues with redirected application data on a server 2008 terminal server
so the real problem here is not that adobe writes crappy code. the real problem is that adobe wrote some crappy code and has not fixed it.

here is the problem: if you are running redirected folders in an AD environment and you redirect your application data folder, adobe acrobat reader 9 will give you a c++ runtime error if you are not an administrator. i have seen several people come up with fixes, one works for some, but not for others, so ymmv.

the three fixes i have seen have been:
1.    give list folder / read data permissions on the root level (applied to this folder only) of your users or homes share
2.    create the local low folder
3.    lastly, and the one that i use with a vbscript, is do delete a particular registry key
here was my original code:

Option Explicit

Dim objShell
Set objShell = WScript.CreateObject(“WScript.Shell”)

On Error Resume Next

objShell.RegDelete “HKCUSoftwareMicrosoftActive SetupInstalled Components{89820200-ECBD-11cf-8B85-00AA005B4340}Version”

so, no error checking, and technically speaking it worked, but its ugly. i went back and fixed this to do some logic to see if the key existed before it tried to delete it, and came up with the following:

On Error Resume Next

Const HKEY_CURRENT_USER = &H80000001
strComputer = “.”

Set objRegistry = GetObject(“winmgmts:\” & strComputer & “rootdefault:StdRegProv”)
strKeyPath = “SoftwareMicrosoftActive SetupInstalled Components{89820200-ECBD-11cf-8B85-00AA005B4340}”
strValueName = “Version”
objRegistry.GetStringValue HKEY_CURRENT_USER,strKeyPath,strValueName,strValue

If (IsNull(strValue) = False) Then
     objRegistry.DeleteValue HKEY_CURRENT_USER, strKeyPath, strValueName
End If

for us, running server 2008 terminal servers, this fixed the problem. users are now successfully running the latest version of adobe acrobat reader 9 with no errors.

if you want to see details of the problem, or look at some of the other solutions (the root share permissions fix or the local low fix), you can look at some of the following threads/links. they go into a lot more detail and explain what is happening and what to try to fix it

http://support.microsoft.com/kb/955555/en-us
http://forums.adobe.com/thread/391738?tstart=0
http://forums.adobe.com/thread/303079


read more

i was trying to troubleshoot a remote server 2008 system that where the gui wasn’t responding, you couldn’t log into the machine, but the box was still responding to pings, wmi requests, etc.

my guess is some process is hogging the processor, but without being able to log in, i needed a remote way to do determine if cpu usage is actually the culprit. while there are a few ways that came to mind (wmic, vbscript, etc), i thought of mark russinovich’s pslist tool.

by default, pslist doesn’t show you the cpu usage (it shows cpu time), but with a few options it will spit out what you need. here is what i ended up running:

C:>pslist.exe -s -r 10 -t \remote_computer

this ran pslist in task manager mode (-s, that shows cpu usage in %), refreshed every 10 seconds (-r 10), and in a process tree (-t), which i find handy for certain situations, all against the remote computer (\remote_computer).

obviously you will need to run this as a user that has domain rights that gives you enough rights to run this command, locally or remotely.

heres a link to the pslist sysinternals website for download or more detailed information: http://technet.microsoft.com/en-us/sysinternals/bb896682.aspx


read more