Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Hey all, Ned here. The Building Windows 8 blog recently posted a new article from Chris Clark that you might have passed over due to the title, which sounds like another article on boot performance:
Designing for PCs that boot faster than ever before
Don’t skip it! A more descriptive title would have been “The F8 and F2 boot menus are gone on Windows 8 and you need to read this post to do your job, IT Pro.”
Windows 8 is designed to run on hardware that boots too fast for a human to react through a keyboard, requiring new methods to get to a boot menu. Note down what the article describes so that when you need to troubleshoot a slow logon or slow boot, you can get into Safe Mode and other diagnostic states (PC Settings, shift+restart, shutdown.exe /o /r, msconfig.exe). All of these apply to Windows 8 Developer Preview and Windows Server “8” Beta, which you can get your hot little hands on right now.
It is also important to note – and not mentioned in the article – that on Windows Server 2012 only, you can still use F8. The new boot menu system eventually gets you back to the familiar menu with your favorite DSRM option too, so don’t feel like we’re making you relearn everything:
Also not mentioned but preemptively answered now: while shutdown /o was updated to support the new boot menus, the restart-computer Windows PowerShell cmdlet was not.
- Ned “Doc Martens” Pyle
Hey all, Ned here with a quick “xerox” post: the Dynamic Access Control developers have released a good intro on their octo-feature through the Windows Server Blog:
Introduction to Windows Server 2012 Dynamic Access Control
It’s written by Nir Ben-Zvi, a Program Manager on the Windows Server development team. If you’re unfamiliar with DAC, this is a great first read. Here’s a quote:
These focus areas were then translated to a set of Windows capabilities that enable data compliance in partner and Windows-based solutions.
Click to the read the rest.
If you are looking for more depth and “how it works”, check out our very own Mike Stephens’ downloadable whitepaper:
Understand and Troubleshoot Dynamic Access Control in Windows Server "8" Beta
Until next time,
Ned “10 cent copies” Pyle
Hi folks, Ned here again. It’s been a little while since the last sack, but I have a good excuse: I just finished writing a poop ton of Windows Server 2012 depth training that our support folks around the world will use to make your lives easier (someday). If I ever open MS Word again it will be too soon, and I’ll probably say the same thing about PowerPoint by June.
Anyhoo, let’s get to it. This week we talk about:
Is it possible to use any ActiveDirectory module cmdlets through invoke-command against a remote non-DC where the module is installed? It always blows up for me as it tries to “locally” (remotely) use the non-existent ADWS with error “Unable to contact the server. This may be because the server does not exist, it is currently down, or it does not have the active directory web services running”
Yes, but you have to ignore that terribly misleading error and put your thinking cap on: the problem is your credentials. When you invoke-command, you make the remote server run the local PowerShell on your behalf. In this case that remote command has to go off-box to yet another remote server – a DC running ADWS. This means a multi-hop credential scenario. Provide –credential (get-credential) to your called cmdlets inside the curly braces and it’ll work fine.
We are using a USMT /hardlink migration to preserve disk space and increase performance. However, performance is crazy slow and we’re actually running out of disk space on some machines that have very large files like PSTs. My scanstate log shows:
Error [0x000000] Write error 112 for C:\users\ned\Desktop [somebig.pst]. Windows error 112 description: There is not enough space on the disk.[gle=0x00000070] Error [0x080000] Error 2147942512 while gathering object C:\users\ned\Desktop\somebig.pst. Shell application requested abort![gle=0x00000070]
Error [0x000000] Write error 112 for C:\users\ned\Desktop [somebig.pst]. Windows error 112 description: There is not enough space on the disk.[gle=0x00000070]
Error [0x080000] Error 2147942512 while gathering object C:\users\ned\Desktop\somebig.pst. Shell application requested abort![gle=0x00000070]
These files are encrypted and you are using /efs:copyraw instead of /efs:hardlink. Encrypted files are copied into the store whole instead of hardlink'ing, unless you specify /efs:hardlink. If you had not included /efs, this file would have failed with, "File X is encrypted. Use the /efs option to specify a different way to handle this file".
Yes, I realize that we should probably just require that option. But think of all the billable hours we just gave you!
I was using your DFSR pre-seeding post and am finding that robocopy /B is slows down my migration compared to not using it. Is that required for preseeding?
The /B mode, while inherently slower, ensures that files are copied using a backup API regardless of permissions. It is the safest way, so I took the prudent route when I wrote the sample command. It’s definitely expected to be slower – in my semi-scientific repro’s the difference was ~1.75 times slower on average.
However, /B not required if you are 100% sure you have at least READ permissions to all files. As a middle ground approach, you might consider using /ZB to be somewhat faster but then hopefully still copy if there are issues; the downside here is a lot of failures due to permissions might end up making things even slower than just going /B; you will have to test it. You can also add /MT to offset the /B slowness.
Recently I came across an user account that keeps locking out (yes, I've read several of your blogs where you say account lockout policies are bad "Turning on account lockouts is a way to guarantee someone with no credentials can deny service to your entire domain"). We get the Event ID of 4740 saying the account has been locked out, but the calling computer name is blank:
Log Name: Security
Event ID: 4740
Level: Information
Description:
A user account was locked out.
Subject:
Security ID: SYSTEM
Account Name: someaccount
Account Domain: somedomain
Logon ID: 0x3e7
Account That Was Locked Out:
Security ID: somesid
Account Name: someguy
Additional Information:
Caller Computer Name:
The 0xC000006A indicates a bad password attempt. This happens every 5 minutes and eventually results in the account being locked out. We can see that the bad password attempts are coming via COMP1 (which is a proxy server) however we can't work out what is sending the requests to COMP1 as the computer is blank again (there should be a computer name).
Are we missing something here? Is there something else we could be doing to track this down? Is the calling computer name being blank indicative of some other problem or just perhaps means the calling device is a non-Microsoft device?
(I am going to channel my inner Eric here):
A blank computer name is not unexpected, unfortunately. The audit system relies on the sending computers to provide that information as part of the actual authentication attempt. Kerberos does not have a reliable way to provide the remote computer info in many cases. Name resolution info about a sending computer is also easily spoofed. This is especially true with transitive NTLM logons, where we are relying on one computer to provide info for another computer. NTLM provides names but they are also easily spoofed so even when you see a computer name in auditing, you are mainly asking an honest person to tell you the truth.
Since it happens very frequently and predictably, I’d configure a network capture on the sending server to run in a circular fashion, then wait for the lock out and stop the event. You’d see all of the traffic and now know exactly who sent it. If the lockout was longer running and less predictable, I’d recommend using a network capture configured to trace in a circular fashion until that 4740 event writes. Then you can see what the sending IP address is and hunt down that machine. Different techniques here:
[And the customer later noted that since it’s a proxy server, it has lots of logs – and they told him the offender]
I am testing USMT 5.0 and finding that if I migrate certain Windows 7 computers to Windows 8 Consumer Preview, Modern Apps won’t start. Some have errors, some just start then go away.
Argh. The problem here is Windows 7’s built-in manifest that implements microsoft-windows-com-base , which then copies this registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
If the DCOM permissions are modified in that key, they migrate over and interfere with the ones needed by Modern Apps to run. This is a known issue and already fixed so that we don’t copy those values onto Windows 8 anymore. It was never a good idea in the first place, as any applications needing special permissions will just set their own anyways when installed.
And it’s burned us in the past too…
Are there any available PowerShell, WMI, or command-line options for configuring an OCSP responder? I know that I can install the feature with the Add-WindowsFeature, but I'd like to script configuring the responder and creating the array.
[Courtesy of the Jonathan “oh no, feet!” Stephens – Ned]
There are currently no command line tools or dedicated PowerShell cmdlets available to perform management tasks on the Online Responder. You can, however, use the COM interfaces IOCSPAdmin and IOSCPCAConfiguration to manage the revocation providers on the Online Responder.
Because these are COM interfaces, you can call them from VBScript or PowerShell, so you have great flexibility in how you write your script.
I want to use Windows Desktop Search with DFS Namespaces but according to this TechNet Forum thread it’s not possible to add remote indexes on namespaces. What say you?
There is no DFSN+WDS remote index integration in any OS, including Windows 8 Consumer Preview. At its heart, this comes down to being a massive architectural change in WDS that just hasn’t gotten traction. You can still point to the targets as remote indexes, naturally.
Certain files – as pointed out here by AlexSemi – that end with invalid characters like a dot or a space break USMT migration. One way to create these files is to use the echo command into a device path like so:
These files can’t be opened by anything in Windows, it seems.
When you try to migrate, you end up with a fatal “windows error 2” “the system cannot find the file specified” error unless you skip the files using /C:
What gives?
Quit making invalid files! :-)
USMT didn’t invent CreateFile() so its options here are rather limited… USMT 5.0 handles this case correctly through error control - it skips these files when hardlink’ing because Windows returns that they “don’t exist”. Here is my scanstate log using USMT 5.0 beta, where I used /hardlink and did NOT provide /C:
In the case of non-hardlink, scanstate copies them without their invalid names and they become non-dotted/non-spaced valid files (even in USMT 4.0). To make it copy these invalid files with the actual invalid name would require a complete re-architecting of USMT or the Win32 file APIs. And why – so that everyone could continue to not open them?
In case you missed it, Windows 8 Enterprise Edition details. With all the new licensing and activation goodness, Enterprise versions are finally within reach of any size customer. Yes, that means you!
Very solid Mother’s Day TV mash up (a little sweary, but you can’t fight a something that combines The Wire, 30 Rock, and The Cosbys)
Zombie mall experience. I have to fly to Reading in June to teach… this might be on the agenda
Well, it’s about time - Congress doesn't "like" it when employers ask for Facebook login details
Your mother is not this awesome:
That, my friend, is a Skyrim birthday cake
SportsCenter wins again (thanks Mark!)
Don’t miss the latest Between Two Ferns (veeerrrry sweary, but Zach Galifianakis at his best; I just wish they’d add the Tina Fey episode)
But what happens if you eat it before you read the survival tips, Land Rover?!
- Ned “demon spawn” Pyle
Hi all, Ned here again. We get emailed here all the time about issues involving delays in user logons. Often enough that, a few years back, Bob wrote a multi-part article on the subject.
Taking it to the next level, some of my esteemed colleagues have created a multi-part TechNet Wiki series on understanding, analyzing, and troubleshooting slow logons and slow boots. These include:
Before you shrug this off, consider the following example, where we assume for our hypothetical company:
That means an annual cost of:
Benjamin Franklin would not be pleased
Even if you take just the understated US Bureau of Labor private sector compensation cost numbers (roughly $0.50 average employee total compensation cost per minute), you are still hemorrhaging cash. And those numbers just cover direct compensation and benefit costs, not all the other overhead that goes into an employee, as well as the fact that they are not producing anything during that time - you are paying them to do nothing. Need I mention that the computer-using employees are probably costing you nearly twice that number?
Get to reading, people – this is a big deal.
- Ned “a penny saved is a penny earned” Pyle
Hi all, Ned here again with an actual back to back mail sack. This week we discuss:
I was reading an article that showed how to update the computer description every time a user logs on. A commenter mentioned that people should be careful as the environment could run out of USNs if this was implemented. Is that true?
This was a really interesting question. The current USN is a 64-bit counter maintained by each Active Directory domain controller as the highestCommittedUsn attribute on rootDSE. Being an unsigned 64-bit integer, that means 264-1, which is 18,446,744,073,709,551,615 (i.e. 18 quintillion). Under normal use that is never going to run out. Even more, when AD reaches that top number, it would restart at 1 all over again!
Let's say I want to run out of USNs though, so I create a script that makes 100 object write updates per second on at DC. It would take me 54 days to hit the first 1 billionth USN. At that rate, this means I am adding ~6.5 billion USN changes a year. Which means at that rate, it would take just under 3 billion years to run out on that DC. Which is probably longer than your hardware warranty.
My further thought was around Version metadata, which we don't document anywhere I can find. That is an unsigned 32-bit counter for each attribute on an object and again, so huge it is simply not feasible that it would run out in anything approaching normal circumstances. If you were to update a computer’s description every time a user logged on and they only had one computer, at 232-1 that means they have to logon 4,294,967,295 times to run out. Let’s say they logon in the morning and always logoff for bathroom, coffee, meetings and lunch breaks rather than locking their machines – call it 10 logons a day and 250 working days a year. That is still 1.7 million years before they run out and you need to disjoin, rename, and rejoin their computer so they can start again.
That said - the commenter was a bit off about the facts, but he had the right notion: not re-writing attributes with unchanged data is definitely a good idea. Less spurious work is always the right answer for DC performance and replication. Figure out a less invasive way to do this, or even better, use a product like System Center Config Manager; it has built in functionality to determine the “primary user” of computers, involving auditing and some other heuristics. This is part of its “Asset Intelligence” reporting (maybe called something else in SCCM 2012).
Interesting side effect of this conversation: I was testing all this out with NTDSUTIL auth restores and setting the version artificially high on an object with VERINC. Repadmin /showmeta gets upset once your version crosses the 231 line. :) See for yourself (in a lab only, please). If you ever find yourself in that predicament, use LDP's metadata displayer, it keeps right on trucking.
Maybe a li'l ol' casting issue here
Ahh, that's better. Get out the hex converter.
I find replication to be faster with RDC disabled on my LAN connected servers (hmmm, just like your blog said), so I have it disabled on the connections between my hub servers and the other servers on the same LAN. I have other servers connected over a WAN, so I kept RDC enabled on those connections.
By having some connections with RDC enabled and others disabled, am I making my hub server do ‘twice’ the work? Would it be better if I enabled it on all connections, even the LAN ones?
You aren’t making your servers do things twice, per se; more like doing the same things, then one does a little more.
Consider a change made on the hub: it still stage the same file once, compresses it in staging once, creates RDC signatures for it once, and sends the overall calculated SHA-1 file hash to each server once. The only difference will be that one spoke server then receives the whole file and the other spoke does the RDC version vector and signature chunk dance to receive part of the file.
The non-RDC LAN-based communication will still be more efficient and fast within its context, and the WAN will still get less utilization and faster performance for large files with small changes.
I'm trying to get Network Policy Server (RADIUS) to work in my environment to enable WPA-2 authentication from a slick new wireless device. I keep getting the error "There is no domain controller available for domain CONTOSO.COM" in the event log when I try to authenticate, which is our legacy dotted NetBIOS domain name. On a hunch, I created a subdomain without a dot in the NetBIOS name and was able to authenticate right away with any user from that subdomain. Do you have any tricks or advice on how to deal with NPS in a dotted domain running in native Windows 2008 R2 mode other than renaming it (yuck).
I don't even know how to spell NPS (it's supported by our Networking team) but I found this internal article from them. You are not going to like the answer:
Previous versions of IAS/NPS could not perform SPN lookups across domains because it treated the SPN as a string and not an FQDN. Windows Server 2008 R2 corrected that behavior, but now NPS is treating a dotted NetBIOS name as a FQDN and NPS performs a DNS lookup on the CONTOSO.COM name. This fails because DNS does not host a CONTOSO.COM zone.
That leaves you with three main solutions:
There might be some other workaround - this would be an extremely corner case scenario and I doubt we've explored it deeply.
The third solution is an ok short-term workaround, but Win2008 isn’t going to be supported forever and you might need some R2 features in the meantime. The first two are gnarly, but I gotta tell ya: no one is rigorously testing dotted NetBIOS names anymore, as they were only possible from NT 4.0 domain upgrades and are as rare as an honest politician. They are ticking time bombs. A variety of other applications and products fail when trying to use dotted NetBIOS domain names and they might not have a workaround. A domain rename is probably in your future, and it's for the best.
We are using USMT 4.0 to migrate data with the merge script sourcepriority option to always overwrite data on the destination with data from the source. No matter what though, the destination always wins and the source copy of the file is renamed with the losing (1) tag.
This turned out to be quite an adventure.
We turned on migdiag logging using SET MIG_ENABLE_DIAG=migdiag.xml in order to see what was happening here; that's a great logging option for figuring out why your rules aren’t processing correctly. When it got to the file in question during loadstate, we saw this weirdness:
<Pattern Type="File" Path="C:\Users\someuser\AppData\Local\Microsoft\Windows Sidebar [Settings.ini]" Operation="DynamicMerge,<unknown>"/>
Normally, it should have looked like:
<Pattern Type="File" Path="C:\Users\someuser\AppData\Roaming\Microsoft\Access\* [*]" Operation="DynamicMerge,CMXEMerge,CMXEMergeScript,MigXmlHelper,SourcePriority"/>
More interestingly, none of us could reproduce the issue here using the customer's exact same XML file. Finally, I had him reinstall USMT from a freshly downloaded copy of the WAIK, and it all started working perfectly. I've done this a few times in the past with good results for these kinds of weirdo issues; since USMT cannot be installed on Windows XP, it just gets copied around as folders. Sometimes people start mixing in various versions and DLLS, from Beta, RC, and hotfixes, and you end up with something that looks like USMT - but ain't.
Is teaming network adapters on Domain Controllers supported by Microsoft? I found KB http://support.microsoft.com/kb/278431.
(Updated) Maybe! :-D We're still in beta and need to get a final word. Sharp-eyed readers know I was already asked this before. However, I have a new answer for Windows Server: yes, if you use Windows Server "8" Beta.
Whoa, we joined the 1990s! Seriously though, NIC teaming is the bane of our Networking Support group's existence, so hopefully by creating and implementing our own driver system, we stop the pain customers have using third party solutions of variable quality. At least we'll be able to see what's wrong now if it doesn’t work.
For a lot more info, grab the whitepaper. I'm confirming the whole DC-specific aspect here as well. I have heard several stories now and I want to be nice and crisp; check back later. :)
What are the DFSR files $db_dirty$, $db_normal$, and $db_lost$ mentioned in the KB article Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows ? I only see $db_normal$ on my servers (presumably that's a good thing).
$Db_dirty$ exists after a dirty database shutdown and acts as a marker of that fact. $Db_normal$ exists when there are no database issues and is renamed to $db_lost$ if the database goes missing, also acting as a state marker for DFSR between service restarts.
Where is the best place to learn more about MaxConcurrentAPI?
Right here, and only quite recently:
http://social.technet.microsoft.com/wiki/contents/articles/9759.configuring-maxconcurrentapi-for-ntlm-pass-through-authentication.aspx
If you missed it, we released a new hotfix for DFSR last month that adds some long-sought functionality for file server administrators: the ability to prevent DFSR from non-authoritatively synchronizing replicated folders on a volume where the database suffered a dirty shutdown:
Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2 - http://support.microsoft.com/kb/2663685
DFSR now provides the capability to override automatic replication recovery of dirty shutdown-flagged databases. By default, the following registry DWORD value exists:
HKLM\System\CurrentControlSet\Services\DFSR\Parameters\
StopReplicationOnAutoRecovery = 1
If set to 1, auto recovery is blocked and requires administrative intervention. Set it to 0 to return to the old behavior.
DFSR writes warning 2213 event to the DFSR event log:
MessageId=2213
Severity=Warning
Message=
The DFS Replication service stopped replication on volume %2.
This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.
Volume: %2
GUID: %1
Recovery Steps
1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
2. To resume the replication for this volume, use the WMI method ResumeReplication of the VolumeConfig class.
For example, from an elevated command prompt, type the following command:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="%1" call ResumeReplication
For more information, see http://support.microsoft.com/kb/2663685.
You must then make a decision about resuming replication. You must weigh your decision against the environment:
You then have several options:
Example:
Wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="<some GUID>" call ResumeReplication
Holy crap!
Pandora.com is a great way to find new music; I highly recommend it. It can get a little esoteric, though. Real radio will never find you a string duo that plays Guns and Roses songs, for example.
AskDS reader Joseph Moody sent this along to us:
"Because I got tired of forwarding the Accelerating Your IT Career post to techs in our department, we just had it printed poster size and hung it on an open wall. Now, I just point to it when someone asks how to get better."
My wife wanted to be a marine biologist (like George Costanza!) when she was growing up and we got on a killer whale conversation last week when I was watching the amazing Discovery Frozen Planet series. She later sent me this tidbit:
"First, the young whale spit regurgitated fish onto the surface of the water, then sank below the water and waited. If a hungry gull landed on the water, the whale would surge up to the surface, sometimes catching a free meal of his own. Noonan watched as the same whale set the same trap again and again. Within a few months, the whale's younger half brother adopted the practice. Eventually the behavior spread and now five Marineland whales supplement their diet with fresh fowl, the scientist said."
"First, the young whale spit regurgitated fish onto the surface of the water, then sank below the water and waited.
If a hungry gull landed on the water, the whale would surge up to the surface, sometimes catching a free meal of his own. Noonan watched as the same whale set the same trap again and again. Within a few months, the whale's younger half brother adopted the practice.
Eventually the behavior spread and now five Marineland whales supplement their diet with fresh fowl, the scientist said."
It's Deep Blue Sea for Realzies!!!
Have you ever wanted to know what AskDS contributor Rob Greene looks like when his manager 'shops him to a Shrek picture? Now you can:
Have a nice weekend folks,
- Ned “” Pyle
Hi all, Ned here again. I have worked many slow boot and slow logon cases over my career. The Directory Services support team here at Microsoft owns a sizable portion of those operations - user credentials, user profiles, logon and startup scripts, and of course, group policy processing. If I had to pick the initial finger pointing that customers routinely make, it's GP. Perhaps it's because group policy is the least well-understood part of the process, or maybe because it's the one with the most administrative fingers in the pie. When it comes down to reality though, group policy is more often not the culprit. Our new changes in Windows 8 will help you make that determination much quicker now.
Today I am going to talk about one of those times that GPO is the villain. Well, sort of... he's at least an enabler. More appropriately, the optional WMI Filtering portion of group policy using the Win32_Product class. Win32_Product has been around for many years and is both an inventory and administrative tool. It allows you to see all the installed MSI packages on a computer, install new ones, reinstall them, remove them, and configure them. When used correctly, it's a valuable option for scripters and Windows PowerShell junkies.
Unfortunately, Win32_Product also has some unpleasant behaviors. It uses a provider DLL that validates the consistency of every installed MSI package on the computer - or off of it, if using a remote administrative install point. That makes it very, very slow.
Where people trip up usually is group policy WMI filters. Perhaps the customer wants to apply managed Internet Explorer policy based on the IE version. Maybe they want to set AppLocker or Software Restriction policies only if the client has a certain program installed. Perhaps even use - yuck - Software Installation policy in a more controlled fashion.
Today I talk about some different options. Mike didn’t write this but he had some good thoughts when we talked about this offline so he gets some credit here too. A little bit. Tiny amount, really. Hardly worth mentioning.
If you have no idea what group policy WMI filters are, start here:
Back? Great, let's get to it.
The Win32_Product WMI class is part of the CIMV2 namespace and implements the MSI provider (msiprov.dll and associated msi.mof) to list and validate installed installation packages. You will see MsiInstaller event 1035 in the Application log for each application queried by the class:
Source: MsiInstaller Event ID: 1035 Description: Windows Installer reconfigured the product. Product Name: <ProductName>. Product Version: <VersionNumber>. Product Language: <languageID>. Reconfiguration success or error status: 0.
And constantly repeated System events:
Event Source: Service Control Manager Event ID: 7035 Description: The Windows Installer service was successfully sent a start control. Event Type: Information Event Source: Service Control Manager Event ID: 7036 Description:
Event Source: Service Control Manager
Event ID: 7035
The Windows Installer service was successfully sent a start control.
Event Type: Information
Event ID: 7036
That validation piece is the real speed killer. So much, in fact, that it can lead to group policy processing taking many extra minutes in Windows XP when you use this class in a WMI filter - or even cause processing to time out and fail altogether.. This is even more likely when:
Furthermore, Windows Vista and later Windows versions cap WMI filters execution times at 30 seconds; if they fail to complete by then, they are treated as FALSE. On those OS versions, it will often appear that Win32_Product just doesn’t work at all.
What are your alternatives?
Depending on what you are trying to accomplish, Group Policy Preferences could be the solution. GPP includes item-level targeting that has fast, efficient filtering of just about any criteria you can imagine. If you are trying to set some computer-based settings that a user cannot change and don’t mind preferences instead of managed policy settings, GPP is the way to go. As with all software, make sure you evaluate our latest patches to ensure it works as desired. As of this writing, those are:
For instance, let's say you have a plotting printer that Marketing cannot correctly use without special Contoso client software. Rather than using managed computer policy to control client printer installation and settings, you can use GPP Registry or Printer settings to modify the values needed.
Then you can use Item Level Targeting to control the installation based on the specialty software's presence and version.
Alternatively, you can use the registry and file system for your criteria, which works even if the software doesn't install via MSI packages:
What to do if you really, really need to use a WMI filter to determine MSI installed versions and names though? If you look around the Internet, you will find a couple of older proposed solutions that - to be frank - will not work for most customers.
The Win32reg_AddRemovePrograms is not present on most client systems though; it is a legacy class, first delivered by the old SMS 2003 management WMI system. I suspect one of the reasons the System Center folks discarded its use years ago for their own native inventory system was the same reason that the customer class above doesn’t work in #2 - it didn’t return 32-bit software installed on 64-bit computers. The class has not been updated since initial release 10 years ago.
#2 had the right idea though, at least as a valid customer workaround to avoid using Win32_Product: by creating your own WMI class using the generic registry provider to examine just the MSI uninstall registry keys, you can get a fast and simple query that reasonably detects installed software. Armed with the "how", you can also extend this to any kind of registry queries you need, without risk of tanking group policy processing. To do this, you just need notepad.exe and a little understanding of WMI.
Windows Management Instrumentation uses Managed Operation Framework (MOF) files to describe the Common Information Model (CIM) classes. You can create your own MOF files and compile them into the CIM repository using a simple command-line tool called mofcomp.exe.
You need to be careful here. This means that once you write your MOF you should validate it by using the mofcomp.exe -check argument on your standard client and server images. It also means that you should test this on those same machines using the -class:createonly argument (and not setting the -autorecover argument or #PRAGMA AUTORECOVER pre-processor) to ensure it doesn't already exist. The last thing you want to do is break some other class.
When done testing, you're ready to give it a go. Here is a sample MOF, wrapped for readability. Note the highlighted sections that describe what the MOF examines and what the group policy WMI filter can use as query criteria. Unlike the oft-copied sample, this one understands both the normal native architecture registry path as well as the Wow6432node path that covers 32-bit applications installed on a 64-bit system.
Start copy below =======>
// "AS-IS" sample MOF file for returning the two uninstall registry subkeys
// Unsupported, provided purely as a sample
// Requires compilation. Example: mofcomp.exe sampleproductslist.mof
// Implements sample classes: "SampleProductList" and "SampleProductlist32"
// (for 64-bit systems with 32-bit software)
#PRAGMA AUTORECOVER
[dynamic, provider("RegProv"),
ProviderClsid("{fe9af5c0-d3b6-11ce-a5b6-00aa00680c3f}"),ClassContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall")]
class SampleProductsList {
[key] string KeyName;
[read, propertycontext("DisplayName")] string DisplayName;
[read, propertycontext("DisplayVersion")] string DisplayVersion;
};
ProviderClsid("{fe9af5c0-d3b6-11ce-a5b6-00aa00680c3f}"),ClassContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432node\\Microsoft\\Windows\\CurrentVersion\\Uninstall")]
class SampleProductsList32 {
<======= End copy above
Examining this should also give you interesting ideas about other registry-to-WMI possibilities, I imagine.
Copy this sample to a text file named with a MOF extension, store it in the %systemroot%\system32\wbem folder on a test machine, and then compile it from an administrator-elevated CMD prompt using mofcomp.exe filename. For example:
To test if the sample is working you can use WMIC.EXE to list the installed MSI packages. For example, here I am on a Windows 7 x64 computer with Office 2010 installed; that suite contains both 64 and 32-bit software so I can use both of my custom classes to list out all the installed software:
Note that I did not specify a namespace in the sample MOF, which means it updates the \\root\default namespace, instead of the more commonly used \\root\cimv2 namespace. This is intentional: the Windows XP implementation of registry provider is in the Default namespace, so this makes your MOF OS agnostic. It will work perfectly well on XP, 2003, 2008, Vista, 7, or even the Windows 8 family. Moreover, I don’t like updating the CIMv2 namespace if I can avoid it - it already has enough classes and is a bit of a dumping ground.
Now I need a way to get this MOF file to all my computers. The easiest way is to return to Group Policy Preferences; create a GPP policy that copies the file and creates a scheduled task to run MOFCOMP at every boot up (you can change this scheduling later or even turn it off, once you are confident all your computers have the new classes).
You can also install and compile the MOF manually, use psexec.exe, make it part of your standard OS image, deploy it using a software distribution system, or whatever. The example above is just that - an example.
Now that all your computers know about your new WMI class, you can create a group policy WMI filter that uses it. Here are a couple examples; note that I remembered to change the namespace from CIMv2 to DEFAULT!
You're in business with a system that, while not optimal, is certainly is far better than Win32_Product. It’s fast and lightweight, relatively easy to manage, and like all adequate solutions, designed not to make things worse in its efforts to make things different.
AskDS contributor Fabian Müller had another idea that he uses with customers:
1. Define environment variables using GPP based on Registry Item-Level targeting filters or just deploy the variables during software installation phase, e.g. %IEversion%= 9
2. Use this environment variable in WMI filters like this: Root\CIMV2;SELECT VARIABLEVALUE FROM Win32_Environment WHERE NAME='IEversion' AND VARIABLEVALUE='9'
Disadvantage: First computer start or user logon will not pass the WMI filter since the ENV variable had to be created (if set by GPP). It would be better having this environment variable being created during softwareinstallation / deployment (or whatever software being deployed).
Advantage: The environment WMI query is very fast compared. And you can use it “multi-purpose”. For example, as part of CMD-based startup and logon scripts.
Software Installation policy is not designed to be an enterprise software management solution and neither are individual application self-update systems. SI works fine in a small business network as a "no frills" solution but doesn’t offer real monitoring or remediation, and requires too much of the administrator to manage. If you are using these because of the old "we only fix IT when it's broken" answer, one argument you might take to management is that you are broken and operating at great risk: you have no way to deploy non-Microsoft updates in a timely and reliable fashion.
Even though the free Windows Update and Windows Software Update Service support Windows, Office, SQL, and Exchange patching, it’s probably not enough; anyone with more than five minutes in the IT industry knows that all of your software should be receiving periodic security updates. Does anyone here still think it's safe to run Adobe, Oracle, or thousands of other vendor products without controlled, monitored, and managed patching? If your network doesn't have a real software patching system, it's like a building with no sprinklers or emergency exits: nothing to worry about… until there's a fire. You wouldn’t run computers without anti-virus protection, but the number of customers I speak to that have zero security patching strategy is very worrying.
It's not 1998 anymore, folks. A software and patch management system isn’t an option anymore if you have a business with more than a hundred computers; those days are done for everyone. Even for Apple, although they haven't realized it yet. We make System Center, but there are other vendors out there too, and I’d rather you bought a competing product than have no patch management at all.
- Ned "pragma-tism" Pyle
Ok, that might have been a slightly inflammatory and misleading title.
That server name also tells you two things: One, if you had bet against that name in the office pool, you are a born loser. Two, that we may make radical changes in OS capabilities, but when it comes to server branding, we are more conservative than a prom chaperon. Who is also a nun. And voted libertarian. In Switzerland.
Back to work, you!
- Ned "Ned Pyle" Pyle