Default Printer At First Logon via Group Policy

Deploying a network printer via Group Policy is pretty easy. In Group Policy Management Editor, you go to User Configuration > Preferences > Control Panel Settings > Printers and right click to create a new Shared Printer. Configure the options which are pretty straight forward.

Something doesn’t go right though, if you use the option ‘set this printer as the default printer’. The printer won’t actually be set as default for the first login. As it’s set to Update though, this will get fixed next time Group Policy runs.

However, if you have the Action set to ‘Create’, it only gets one chance to set the default printer – at the time of creation. That fails, and it doesn’t get a chance to set the default printer again.

Why does it fail to set the default printer at first logon? You’ll see an event viewer application error like this:

The user ‘HP Printer’ preference item in the ‘Define Printers {XXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}’ Group Policy object did not apply because it failed with error code ‘0x80070709 The printer name is invalid.’ This error was suppressed.

There’s a clear Microsoft Support Article that explains why – in summary, Windows isn’t ready yet to change something on the printer between the time it creates the printer, and then tries to make it default as they’re two separate actions.

However, we can work around this by deploying a registry entry that sets the default printer. This 11 year old article is still correct in that it shows the registry value to change:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

REG_SZ - Device
Value - \\adamfowlerit\printer,winspool,Ne04:e

Setting this via registry as an ‘Apply once and do not reapply’ with any other logic matching your printer deployment policy, should end up with the printer as a default on first logon.

This is a problem that’s been around for many years, but the first time I’ve hit it!

Also, if you’re wondering what the ‘Ne04’ part means, it seems to be some sort of counter which goes up for each time you install a printer.

How To Grep in PowerShell

For those who have lived in the Linux/Unix command line, the ‘grep‘ command is a commonly used way of finding something that you want in a chunk of data.

Øyvind Kallstad did a great writeup of comparing a bunch of ways to use PowerShell instead of grep which is worth reading.

The article covers a bunch of scenarios, and is centered around starting with the ‘grep’ command and working with it. However, there’s the other common use case of running a different command, then piping those results to grep to search for something.

This blogpost was triggered by Janet who asked me this fair question:

As with poor cute cats, there’s more than one way to skin PowerShell.

I had to do some research and asking around on this, because normally I’d filter out the property of the object I was looking at, and work with that. Using the get-process example:

get-process | where ProcessName -like "*foo*

That works, but it’s still a lot clunkier than what a grep user would expect. An easier way would be to use the ‘findstr‘ program (which also has a bunch of useful swtiches):

get-process | findstr foo

I say program because ‘findstr’ is not a PowerShell cmdlet, but it’s still native to Windows and works perfectly fine. It’s case sensitive though, so you need to use -i for case insensitive results.

That’s great for simple stuff, but we’re sort of breaking what PowerShell does. You’re no longer dealing with a standard PowerShell object, so further piping and processing won’t really work.

The ‘proper’ PowerShell way would be to use the ‘Where-Object’ command:

Get-Process | Where-Object {$_ | Select-String "foo"}

A bit longer, but you can shorten ‘Where-Object’ to ‘Where’. Although more involved, it’s good to get into the habit of doing it this way, so when you’re piping this to the next command, it still says as a standard object that can be read and manipulated.’

(Update 24th Feb 2017) As Steve_N points out in the comments section, there’s a much shorter way of doing this:

ps *foo*

That’s it. Many PowerShell commands have inbuilt aliases, including ‘get-process’. You can see what this is with the command ‘get-alias -definition get-process’

This shows that ‘gps’ and ‘ps’ are both aliases to the command  ‘get-process’. You can also create your own aliases with the ‘set-alias‘ command.

The ‘*foo*’ part works because the command assumes the -name switch has been used, which lets you define what criteria to search and show in the ProcessName field. This is the same way that many commands don’t need the -identity switch used, because it’s written to assume you’re going to tell it what identity/username/upn to work with.

This can also be piped to something else, so it’s a winner. It’s less ideal for scripts though, because it’s much harder to read, and you can’t assume that everyone will know the short alias of a full command.

Also note that this isn’t grep related at all, so part of the answer to the original question is that you may not even need grep or select-string as it adds unnecessary overhead of getting data and parsing it, whereas this updated example filters the data as it’s obtained.

(Update ends)

PowerShell isn’t a Linux/Unix command line, but Microsoft have incorporated many of the concepts from bash. If you still can’t bear to use PowerShell on Windows, there’s always the Linux Bash Shell on Windows.

Thanks again to Steve Mclnerey for the grep advice :)

Windows 10 – Time To Get On Board

Windows 10 has been publicly available since 29th July 2015. Since then, Microsoft have been encouraging users to upgrade in many ways – consumers had a year window to upgrade from Windows 7/8/8.1 for free, along with Windows Update prompts reminding consumers that they can do so.

There’s always going to be complaints with any new operating system, but the in-place upgrade process has been the best yet from Microsoft. Gone are the days when any IT professional would strongly avoid it, it’s a much more stable and revertable method.

The upgrade has been optional, but we’re now getting much closer to being forced to go Windows 10 (not that I think this is a bad thing). The two big ways this is happening are:

New PCs with Windows 7 or 8.1 are going to be much less common come November 1, 2016. The top OEM vendors won’t be allowed to do this anymore (E.g. Lenovo, HP, Dell). You could still go to a whitebox builder and buy an OEM version of Windows 7, it just won’t be a pre-packaged option anymore. Windows 7 is very old now, and it’s unrealistic to expect Microsoft as well as all the hardware manufacturers to continue supporting it with new drivers.

The other main driver is Intel’s 7th generation of i series chip, Kaby Lake. This has already been released and seen in some laptops, with desktop CPUs due to be released early 2017. Microsoft is drawing a line in the sand and saying there will be no support at all if you’ve got this new CPU. I have yet to get my hands on a device with these new CPUs to try, so it will be interesting to see if anything breaks with this combination of OS and CPU.

Windows 7 has had a very good run, with great reasons; but the vast improvements that have taken us to Windows 10 (not to mention the better security architecture), as well as internal support for cloud services means this is the way of the future.

If you haven’t started the transition to Windows 10 it’s time to get planning, before you hit the above roadblocks and haven’t put the planning and preparation into the change.


Rolling back from a bad KB Update

Microsoft releases buggy patches now and then (more commonly now sadly).

Today’s stuff up is KB3097877 which breaks a bunch of things, including things like causing Outlook to crash when reading HTML emails.

Best practise is to have a target group from WSUS that these patches go to first, before going company wide – but either way, you’ll want to remove the patch from the affected PCs.

How do you do this? This is my recommended safe approach:

Step 1. Disable the patch in WSUS.
Just do this now, before anyone else gets it. You’re not going to break anything by choosing the ‘Decline’ option on a patch in WSUS. Make sure you do it to each OS version or product you manage (e.g. Windows 7 32 bit, Windows 7 64 bit, Windows 8 32 bit etc).

Step 2. Test uninstalling the patch manually
Before you go nuts and try to fix all the things at once, do a quick test or two. If you manually uninstall the patch, does it successfully uninstall? Reboot and make sure the PC seems happy (check event viewer!). Reboots may take a while doing system state backups and rolling back the patch.

Step 3. – Set WSUS to Uninstall the patch.
It’s a bit counter intuitive to approve a patch to then set it to remove, but that’s how WSUS works. Find the patch by searching for the KB, and once you right click ‘Approve’, you’ll get the option to choose ‘Approved for Removal’. Make sure you’re targeting the correct Computer Group. If you can’t use WSUS, work out how to get your PCs to run a command like this: “wusa /uninstall /kb:3097877 /quiet /norestart” – without the /norestart, they’ll restart :)

Step 4 – Test Windows Update uninstall
Test another PC’s ability to use Windows Updates to uninstall the patch. ‘Checking for updates’ either through the Windows Update GUI or the good old ‘wuauclt /detectnow’ command will do the trick. Similar to Step 2, check it uninstalls and reboot. You can also check C:\Windows\WindowsUpdate.log to make sure it’s happy (this doesn’t apply to Windows 10 as that log doesn’t exist).

Step 5 – Trigger your PCs to check for Windows Updates
Depending on your group policies, Windows Updates will check at certain intervals and may auto download or auto patch. Easiest thing to do is trigger all your PCs to check Windows Updates now. There’s an easy PowerShell way of doing this here, but requires WinRM to be enabled – you should have this on if you want to be able to do a bunch of cool stuff to your PCs. Otherwise, try psexec which will have the same result. This can take a long time to do! Optional component – WOL your PCs first.

Step 6 – Reboot
Now that you’re ready to clean up, test reboot a PC or two and make sure the patch goes away. If that happens, then schedule all your PCs to reboot. You should have a way of doing this already – SCCM can do it well, you can create a once off scheduled task and push that out to PCs, or a bunch of other ways.

Step 7 – Report in WSUS
WSUS has some nice client reporting options. Search for the KB again, right click and choose ‘Status Report’. This is usually not too lagged in it’s information, and you can check to make sure none of your PCs have the update any more. If there’s only a few, it may be easier to manually fix the remainder.


Happy cleaning up!


Windows 8.1 Uptake Will Be Slow for Enterprise

Opinion: Windows 8.1 was officially released on the 18th October 2013. Many people had their hands on it a few weeks earlier, due to Microsoft releasing the RTM version to Technet and MSDN subscribers. People have been waiting for this release, especially with the mixed press around Windows 8. Windows 8.1 seems to address a lot (but not all) of the general complaints out there in consumer land, but for Enterprise it’s a different story.

Windows 8.1 fixes several key complaints – The start button is back to try and lessen the blow in changing how stuff works for users, the Windows App Store now supports a proxy using NTLM Authentication (yes, TMG/ISA!) and many other benefits.

The big show stopper is going to be Internet Explorer. This is one of the main reasons XP has lasted so long in the Enterprise space, when so many companies were stuck with IE6 and couldn’t jump to Vista (OK, nobody really wanted to for other reasons too) as Vista came with IE7 and couldn’t be downgraded. Windows 7 had the same issue, out of the box you get IE8. All it takes is one key Enterprise application that doesn’t support anything above IE6, and you’re stuck on XP until that issue goes away. Now maybe the application works on something newer, but if you run into any issues your huge support dollars are useless, as you’re now running it in an unsupported way.

IE6 finally started to die off and everyone’s now been jumping to Windows 7. The Windows 7 jump forced IE8 onto everyone, and most Enterprise applications touted IE8 as the new standard browser they supported. All was well for a while, and in the meantime IE9 and IE10 were released.

Software developers have been getting better at this overall, and usually IE10 will now be a supported browser. IE10 had been coming since April 2011 and was released September/October 2012 for Windows Server 2012/Windows 8 respectively, and then Windows 7 February 2013. That’s a long window for software developers to start getting on board and supporting it.

Often for support, a product upgrade is required. This can set back a company a reasonable amount, depending how complicated, costly and time consuming the upgrade is – and how other projects are affected.

Windows 8 was brand new when IE10 came out, but Enterprise generally held off due to the major UI change for users, waiting for Windows 8.1 to fix it.

Jump forward to June 2013, and IE11 is first released as a developer preview. Only 3 months from that, and it’s now bundled in with Windows 8.1 and Windows Server 2012 R2. This is an incredibly small window in comparison to IE10, so hardly any developer will support this for quite some time (many are still catching up to IE10).

So where does this leave the SOE for an Enterprise? Stuck on Windows 7. They don’t want to jump to Windows 8 because 8.1 fixes so much, but they can’t jump to 8.1 either because hardly any Enterprise applications will support the default IE11.

Why not just use another browser? Firstly, you need to use one that all the software developers support, and then you’ll run into similar issues around version support and control. Just because Google Chrome does lots of little updates doesn’t make it more stable, you don’t know which next update could potentially break a function, and again you’re stuck with no support by running a version higher than what’s officially recognised.

Why not just use a different software developer? Enterprise applications are often aimed at particular industries, and often there’s a single leader. That generally means you have to start losing functionality, spend huge dollars and time to move away from the product you’ve used, get all your staff retrained and so on. From someone up top, this just seems like a waste of money if you’ve got something that works now.

So, what’s the real solution here? Hopefully competition will play a factor where more versatile software developers can make great products and beat the slower moving ones, but that often takes a long time to occur (the speed of a glacier comes to mind). Solutions like Citrix XenApp or Microsoft App-V for deploying a sandboxed browser to run the app virtually/hosted is a decent workaround, but adds extra complexity.

I think out of necessity, existing software developers will start to adapt faster. Microsoft’s model is moving towards yearly updates for all their products, and that will keep getting shorter and quicker to keep up with the newer players to the industry. Customers will start making this sort of support as high up on the list of demands, rather than asking and accepting what they’re given.

Windows 7 will still be seen as the new XP for a while, but we shouldn’t see such a huge % of Windows 7 PCs out there when it’s life span comes to an end (2020 if you were wondering).

It is still a long way off, but compared to where we are now versus several years ago, we’re doing a lot better. Windows 8.1 will get there, but not until all the legacy apps support IE11.

Update 04/11/2013 – Interesting writeup from Michael Stum, from his website ‘Not Rocket Science’ called “Google Chrome is not usable in a corporate Windows environment” – thanks @nickstugr for the link!