Tag Archives: Group Policy

Parting Scripts – Add a new network printer and set it as default

Some time back, I discovered that a Group Policy Preference that we had applied to a VMware View VDI pool was adding an additional 30 seconds of time staring at the blue spinning donut at each VDI desktop logon.  The policy in question was a printer policy.  Colleagues at other Higher Ed institutions confirmed that they had the same problem with GPP printer preferences.  It has been reported that using the “Mandatory Printers” policy is faster, but this policy does not allow you to assign a default printer.

Enter good old VBScript…

The following script will install a defined network printer and set it as default. If the print share does not exist, an error will be returned. 95% of the code in this script was lifted from my own “KillAndExec.vbs” script from last year. There really is only two lines of new code in here. It is good having a code library to draw on, because it would have taken be days to generate this stuff from scratch. VBScript is so obtuse… so why do I keep using it? Hmmmm….

VDI Profile Loading Delays

We are noticing that it takes rather a long time for users to log in to our VDI environment (~2 minutes, in some circumstances).  I did some analysis of login times using Sysinternals Procmon.  (Enable boot logging, use the “view process tree” feature to look at process times at logon.  See http://blogs.technet.com/b/markrussinovich/archive/2012/07/02/3506849.aspx for details).  What I found was that a child process of explorer.exe called “ie4uinit.exe” was running for most of this time.  This process appears to be part of Microsoft “Active Setup” (discussed in some detail here: http://blog.ressoftware.com/index.php/2011/12/29/disable-active-setup-revealed/).

So what if we disable Active Setup?  Noise on the Internet suggests that this is possible , simply be deleting the key:
HKEY_LOCAL_MACHINESoftwareMicrosoftActive Setup
as suggested here:

However, there is some indication that this could have unintended consequences.  In my case, it immediately caused a logon script to fail to run.  Bummer!

What other solutions are possible?  Members of the Windows in Higher Education mailing list recently recommended using mandatory profiles.  There is a reasonably good rundown of the mandatory profile creation process here:
Missing details are:

  1. It is possible for the mandatory roaming profile to be stored locally (i.e. “C:UsersVDI_Mandatory.V2” to avoid over-the-network profile copy delays.  However, in our View environment, using a network location appears to be faster!
  2. The mandatory roaming profile can be specified using the Group Policy settings in Computer -> Policies -> Administrative Templates -> System -> User Profiles.  (See “Set roaming profile path for all users logging onto this computer” and “Delete cached copies of roaming profile”.)

In testing, I found initial logon times were reduced from two minutes to approximately 20 seconds.  Good!  (But still not great.)  Additional benefits are that it is no longer necessary to run the logon script that I developed to customize the Start Menu and Task Bar.  I also can remove the Group Policy preferences that clean up local profiles on the computer.

DTF – Defragment Them Files – An automated (and free!) approach

One of the fun new bits of system information being collected by System Center Operations Manager 2007 R2 is local drive fragmentation levels.  I knew, back in 2003, when we started going whole-hog with Windows Server deployments, that we would start running into disk fragmentation problems eventually. 

At the time, the boss said “wait until it becomes a problem… we don’t want to buy software that we may not need”.  (Water under the bridge…)  I did implement a local script on a few critical systems to prevent fragmentation, but largely I forgot about it.  Along comes SCOM R2, and now I am being told that over half my servers are over 40% fragmented.  Zounds!  This helped to explain a few (but only a few) system performance issue we were having…

So what to do when you have a big fragmentation problem, and no money to fix it?

Group Policy Client Side Extensions to the rescue again, along with Google, and some VBScript.

I configured a new GP object and associated it with our managed servers.  The policy contains:

  • A “file” Preference which copies the script “defrag2k3LocalDisks.vbs” to the local drive on each managed Server 2003 or Server 2003 R2 system
  • A Scheduled Task Preference which runs this script once per week on each Server 2003 or 2003 R2 system
  • A Scheduled Task Preference which runs the following command on each Server 2008 and Server 2008 R2 system:
    • %windir%system32defrag.exe –c
      (no script is required, as we can defrag all local volumes with a single command)

Yes, we were able to get our systems down to acceptable fragmentation levels within a week, with not a cent spent on defragmentation software.

It is worth mentioning that on some systems, native defrag tools are not enough.  If you have dynamically resized pagefiles, and your systems have been critically low on space for extended periods of time, you may experience significant page file defragmentation.  On 32-bit server operating systems, you could use “pagedefrag.exe” from the SysInternals tool suite to get things under control:

PageDefrag can be set to run on every reboot, and will nicely defrag several files that are normally inaccessible while the OS is running.  Sadly, the tool appears to be a bit out of maintenance.  It will not run on 64-bit systems, for example.

Fortunately, you also can fix page file fragmentation the brute force way… configure the system to use no page file, reboot, and then configure a new, statically-sized page file.  Assuming there is adequate contiguous space on your drive, the new page file should be created with no fragments, and should stay that way.  I am going to assume that this is not a widespread problem for us (perhaps falsely), so I am not going to go looking for trouble by implementing “PageDefrag” across the enterprise (nor am I going to script reporting of page file fragmentation).

Contents of the “defrag2k3LocalDisks.vbs” file follow:

' Defrag2k3LocalDisks.vbs - J. Greg Mackinnon, November 2009
' Runs the native NT defrag utility on all local drives using the Win32_Volume
'   COM object "Defrag" method.
' Tested on Server 2003 only
' Base code taken from somewhere on the Internet... sorry for the lack of
'   attribution.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\" & strComputer & "rootcimv2")

' Creates a collection of disk volume objects, with type of "local"
Set colVolumes = objWMIService.ExecQuery _
    ("Select * from Win32_Volume Where DriveType = '3'")

For Each objVolume in colVolumes
    ' Execute the "Defrag" method on each volume in  the collection.
    ' This will spawn the dfrgifc.exe process.
    errResult = objVolume.Defrag()