As I have mentioned in a previous blog post, several clients who have been using this software for several years with their fleets of Windows 7 desktops with great success. This however changed when testing during the Windows 8.1 deployment we found that it does not work for 8/8.1 this is due to the Remote Registry service no longer being enabled by default.
Now rather than wanting to update the machines manually or to change the service status in the image, I wanted to start this service as this will ensure that all devices turn it on and when I or someone else creates a new image in future, it is one less thing to do. It turns out this is easier to do than I thought it would be.
First you need to open up “Group Policy Management“, find the policy you want to edit by expanding the appropriate trees (or create a new policy within the right scope), right click on it and select “Edit“. This is a computer policy so if like me you limit your GPO’s to work on only users OR computers (Best Practice), then make sure you select a computer enabled policy.
Once you have opened the “Group Policy Management Editor” then you will need to navigate the tree (in the left hand column) to “Computer Configuration” > “Policies” > “Windows Settings” > “Security Settings” > “System Services” and then in the right hand column search out “Remote Registry“, double click on this to open the “Remote Registry Properties” box.
In this box, select the “Define this policy setting” checkbox, which will then in turn enable the options below it, and you simply want to change the “Select service startup mode” radio buttons system to “Automatic”
Now after a group policy update (which can be forced on individual machines via “gpupdate /force“, without the quotes) and a reboot, the machines will have the “Remote Registry” started and running
I know this has been done to death, but as this is my Blog, and the original idea for it was for me to put all the odds and sods of knowledge in one location so I did not have to remember every little command, I am doing it again.
Hyper-V on Server 2008 and 2008 R2 has a known issue with time slipping slipping slipping into the future (sorry Steve Miller Band moment there) when using a Hyper-V based Primary Domain Controller (PDC). The first part of this is an east step, you turn OFF “Time Synchronisation” for the PDC, or whichever server takes care of your time syncing on the network (although I do it for all servers) on the Hyper-V host, this is done by selecting the Virtual Machine in the Hyper Visor, opening its properties, selecting integration services and unchecking “Time Synchronisation” as shown in the image below
Secondly to that, on the PDC you should set a known reliable time source, I normally select one from http://pool.ntp.org.
To add this sever and set it to your PDC time server open an Administrative Command Prompt and enter the following commands
net stop w32time
w32tm /config /manualpeerlist:PEERS /syncfromflags:manual /reliable:yes /update
net start w32time
Where PEERS is the selected time server or time server pool.
This should update itself instantly, and keep itself updated
After a WSUS Rebuild, I started noticing that Machines, although associating with WSUS were showing up that they had not yet reported to the server, upon investigating this it was discovered that the clients were erroring and displaying error code 800B0001. The machine in question hosting WSUS is a 64 Bit Server 2008 R2 machine, with these details in hand I go off looking for a solution.
Today whilst installing a new WSUS server on a 2008R2 Standard server for a client I came across a new error I had not seen before, basically WSUS install got part of the way through and then threw up the error: “Windows Server Update Service 3.0 SP2 could not install WSUSService and the Performance Counters”
To be honest this was a quick fix, basically it in my case came down to entirely the performance counters, which is about a 5 minute check and a 30 second fix
First we want to open RegEdit and check the “Counter” entry under “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib” and then compare it to the last number value in Counter under “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009“. In this case 009 is the locale ID for english, and therefore 009 would be different for other locales
In my case this was all ok, however if it is not you may need to make sure that you have not disabled the Performance Counters, looking under “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib” see if you have the “Disable Perforamance Counters” setting, if it is missing, then do not worry it simply means that they are enabled and never have been disabled (the entry is only generated once the counters have been disabled for the first time). If the key is set (has a value of 1) then turn it off (set it to 0)
Once this is done you need to rebuild the counters, this is thankfully easy to do from the command line, simply open an administrative command prompt and type the following
The first command uses the SystemDir Environmental Variable and the System32 path to drop you into the system 32 directory (Normally C:\Windows\system32, but will change depending on install location, the environmental variable will change so it always points to the correct directory). The second command tells the counters to Rebuild the entries from scratch, alternatively if you have a backup of the perf counters (generated by the lodctr /s:<;filename>; command) you can load it with lodctr /R:<;filename>;
As I said, takes longer to do the checks than it does to apply the fix (isn’t that always the case)