Tech Blog

So recently we took the plunge to auto patch and reboot all our servers based on the following schedules:

Schedule_1 WSUS Auto Approve – 7 days Deadline – When new updates are downloaded by WSUS they are held for 7 days then rolled out to the servers.  The server will then auto install and reboot (if necessary) the Monday after the 7 day deadline expires at 03:00.  Please note all previous updates that are needed will be installed installed on any Monday at 03:00.

Schedule_2 WSUS Auto Approve – 12 days Deadline – When new updates are downloaded by WSUS they are held for 21 days then rolled out to the servers.  The server will then auto install and reboot (if necessary) the Tuesday after the 21 day deadline expires at 02:00.  Please note all previous updates that are needed will be installed installed on any Tuesday at 02:00.

Schedule_3 WSUS Auto Approve – 31 days Deadline – When new updates are downloaded by WSUS they are held for 31 days then rolled out to the servers.  The server will then auto install and reboot (if necessary) the Wednesday after the 31 day deadline expires at 03:00.  Please note all previous updates that are needed will be installed installed on any Wednesday at 03:00.

So in other words patch schedule 1 first and see if the servers break then 5 days later do install the patches on the servers in schedule 2 and then 24 days later do the rest.  I.e. Test, test and finish.

So here’s how we did it:

• On WSUS setup some Computer Groups i.e. Schedule 1, Schedule 2 and Schedule 3:

• Put your servers in these groups (or if you auto place servers in groups via GPO then I cover that later).
• Create some Auto Approval Rules under Options in WSUS manager:
  • The following example only applies Critical and Security updates to Computer Folder Schedule 1 and the deadline to install (i.e. install after) is 7 days at 03:00
  • 
  • 
  • IMPORTANT – Once you’ve created the rules click RUN RULE or the rule wont run against the existing updates.
  • 
• Finally setup the Group Policies for the Servers (example for schedule 1), I applied a security group to the GPO so only the servers in schedule 1 received these updates:
  • Administrative TemplatesWindows Components/Windows Update
    Allow Automatic Updates immediate installation Enabled
    Always automatically restart at the scheduled time EnabledThe restart timer will give users this much time to save their work (minutes): 15

    Configure Automatic Updates Enabled

    Configure automatic updating: 4 – Auto download and schedule the install
    The following settings are only required and applicable if 4 is selected.
    Install during automatic maintenance Disabled
    Scheduled install day: 3 – Every Monday
    Scheduled install time: 03:00
    Enable client-side targeting Enabled

    Target group name for this computer Schedule_1  (Note – if you use GPOs to place servers in computer groups in WSUS then is the setting)
    

    No auto-restart with logged on users for scheduled automatic updates installations Disabled
    Specify intranet Microsoft update service location Enabled

    Set the intranet update service for detecting updates: http://WSUS01:8530
    Set the intranet statistics server: http://WSUS01:8530

That should be it!!!!

So further to my post about roaming profiles going screwy i.e.

When a roaming user logs off their profile isnt fully deleted meaning when they log on they get a second profile on the computer called Username.Domain.

This second profile results in a black background because the following registry key: HKEY\Current User\Control\Desktop\Wallpaper\ points at their orgininal profile which is half deleted.

To fix this you need to ensure the profile is deleted so I’d recommend a policy to turn off the PC’s off in the evening with a shutdown script to run Delprof2.exe.  If this still doesnt work then you can cheat a little and change the registry to point at the roaming profile:

Key: HKEY\Current User\Control\Desktop\Wallpaper\
Value: REG_SZ
Value: \\ProfileServer\Staff_profiles_Share\%username%.v2\appdata\roaming\microsoft\windows\themes\TranscodedWallpaper.jpg
Although if your sensible you would have a mandory wallpaper and wouldnt have this issue (we’re not as users like pictures of their kids).

So I have a ESXi 5.1 set-up at home where I have a few Windows 7 machines running.  After connecting to a win7 VM the other day via RDP I noticed no sound was being passed.  Sound was enabled via RDP which left the VM itself, after some digging I found I had to edit the VMX file of the VM to add sound.  So after turning the VM off and browsing to the datastore I downloaded the VMX file and added these entries:

sound.present = “TRUE”

sound.virtualDev = “es1371”

sound.fileName = “-1”

sound.autodetect = “TRUE”

sound.startConnected = “TRUE”

Once I re-uploaded the VMX, Boom (literally), sound!!

I’m sure you all know what group policiesare as I’m guessing you wouldn’t be here otherwise!

Well here’s a quick how to on the settings you need to set up a login Wallpaper for Win 7:

Firstly you’ll need a Domain Controller running Server 2008 (I used R2) or a Windows 7 workstation with the AD tools installed and be logged on as a admin of some sort (preferably a Domain Admin):

1. open group policy Management.

2. Go to: Computer Configuration\Preferences\Windows Settings\Files

3. Right-click the “Files” icon and click:  New > File

4. Select Replace