I thought this was a VMware issue initially and even blamed BGInfo for reporting spurious network cards on the desktop background, but this appears to be an issue with 2008 R2.
When removing and adding network adapters in 2008 R2 Virtual Machines in VMware, old network adapters are not fully removed from the Network Adapters list of devices in Device Manager.
The network adapter information remains in registry with the old IP address details. This causes issues for reporting software such as BGInfo. Really frikking annoying. Not really plug and play is it.
If you add a new adapter and remove the old adapter and try to use the same IP address, you will get an error message as per KB269155.
You can enable the option to see hidden devices in Device Manager by following these instructions:
- Open a command prompt
- Run ‘set devmgr_show_nonpresent_devices=1’
- Launch device manager by running ‘Start DEVMGMT.MSC’
- Click View, and then click Show Hidden Devices.
Once you can see the old network adapters just uninstall them.
If you are like me and you like to include the latest drivers in your SOE I have a word of warning about the vShield Endpoint Driver.
I included this in our 2008 R2 SP1 SOE as I knew we were going to be rolling out Trend Micro Deep Security.
Bad idea! The vShield Endpoint Driver makes the server practically unusable. You won’t be able to map network drives, you’ll get RPC replication issues, it will behave as if the most anal anti virus software has been installed with all features enabled.
Took me weeks to figure out it was this innocuous driver which wasn’t supposed to be doing anything…
If you’ve had the pleasure of rolling out KMS hosts in an environment where, previously they had been using MAK keys, you’ll notice that if you re-arm KMS clients they will insist on rebooting for the changes to come into effect. Not ideal!
The easiest way I found around this, was to use the provided keys from the Volume Activation Deployment Guide Windows 7. Shown below is the key for 2008 R2 Standard.
Windows Server 2008 R2 Standard Product Key — YC6KT-GKW9T-YTKYR-T4X34-R7VHC
First reset the license key with ‘slmgr -ipk ProductKey’, then force the machine to activate with ‘slmgr -ato’.
Sorted! Reboot avoided.
I recently had to implement KMS and decided on a resilient KMS design with a primary and secondary KMS server. As per Microsoft recommendation a minimum of two KMS hosts are required for fail over. KMS does not need a dedicated server, so you can install it on an existing server, such as a Domain Controller, saving license costs.
All you need to do, to convert an existing server to a KMS server, is to replace it’s existing key with ‘slmgr -ipk NEWKEY’. Wait for the confirmation and then run ‘slmgr -ato’ to activate the new KMS key. You should get a ‘product successfully activated’ reply. Now we have two KMS hosts configured in Active Directory with the same priority and weighting.
To designate between the primary and secondary KMS server, the priority and weighting must be applied to the DNS records associated with each KMS host.
The priority field will determine which host is contacted first – clients always attempt to contact the host with the lowest priority. The weighting field is a load balancing mechanism for hosts with the same priority. As the KMS hosts will be configured as a primary and secondary, I’ve left the weighting value the same.
Additionally as I was using the same KMS servers in an environment with multiple domains, I required DNS records to be published in every domain. The easiest way to manage this is to use the ‘DnsDomainPublishList’ multi-string field. This will configure the KMS servers to automatically publish in multiple DNS domains and set the priority and weighting of each server.
Format: domain to publish in, priority, weighting
Multi String Value
||xyz.com, 10, 100abc.xyz.com, 10, 100
||xyz.com, 20, 100abc.xyz.com, 20, 100
And lastly dont forget to disable KMS client caching on each host with ‘slmgr.vbs /ckhc’. This will force a client to always use KMS auto discovery (query DNS) to determine which KMS host to activate with. If the primary KMS host if offline, the client will automatically activate with the secondary KMS host.
I hate unnecessary event log errors, especially when it some unintelligible bullshit that repeatedly clogs up the event logs, making it harder to troubleshoot real issues.
If you’ve noticed the following below in your 2008 R2 SP1 servers, don’t panic, its not your fault:
Event filter with query “SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA “Win32_Processor” AND TargetInstance.LoadPercentage > 99″ could not be reactivated in namespace “//./root/CIMV2” because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.
Some crappy coder forgets to do their job properly and we end up with event log errors that raise false alarms, finger pointing (usually!) and time wasting.
Whoever was the release manager for SP1 should be fired… Steve Jobs style.
The fix is easier enough. Documented under KB950375 – run a vbs script or install an msi as found in article 2545227. I went the vbs script route, seems to do the job.
I have tested this on a vanilla Windows 2008 R2 SP1 ISO and the error is also present so is indeed a SP1 issue.