and other brilliant error messages

Tag Archives: Group Policy

Simple VPN configurations can be deployed by Group Policy but EAP authentication settings cannot be configured like this, even using Windows 8.1 and Windows Server 2012 R2. Microsoft added some new PowerShell cmdlets to Windows 8.1 for configuring VPNs, but the worked examples do not appear to function for all the settings for PEAP connections, and they do not show a worked example of how you go about exporting and re-importing a connection’s XMLStream.

Defining the XML as a block within the script itself, even assigning it as data type XML does not seem to work. Not being particularly accustomed to PowerShell, the following script took a while to get right. I assigned it as a laptop startup script by GPO. If I need to modify the connection in future I can increment the version number since the script checks the local machine Registry for that, and will not install if the desired version marker is already present.

The goal is installing drivers automatically as printers are connected at logon, without user interaction.
If your users are non-privileged, you will need to add a Group Policy setting to suppress the elevation prompts. Using a PC running Vista or later with the Group Policy Management MMC tool, set:

If your print servers are likely to remain on Windows 2003, you will most likely need to find a way of loading Windows 7 drivers for x86 and x64 architectures. You can’t do this on the Windows 2003 host, however you can accomplish this by using a Windows 7 machine and loading Print Management from Administrative Tools. Then right-click on Print Servers branch and add your 2003 print server. Now you can add the necessary drivers.

The final problem is an intermittent one. Occasionally you will find that documents won’t print, and when you investigate, you will find a document in front of the print job in the print queue called Local Downlevel Document.

According to this thread, it transpires that Windows Vista and newer introduced a new protocol (Asynchronous RPC) and for some reason the OS is too stupid to actually check whether the remote print server supports it before attempting to use it (Windows 2003 does not support it).

The workaround is to set to disable Async RPC on Vista/Windows 7 clients, again by Group Policy. Set the following Registry value:

Most Windows sysadmins use a Group Policy object to launch their login script. You may have noticed that Windows 7 and Vista fail to connect network drives defined in the login script if the user is a local admin and UAC is enabled. The script completes successfully and no error condition is encountered, but no drive mappings. Run it again manually and everything’s fine.

This is in fact by design, and it’s caused by the way UAC works. When you’re a member of the Administrators group and you log in, your account is busted down to a non-privileged user by UAC. This running context is completely separate from the context you get when you right-click Command Prompt and launch as an administrator. As you’ll probably have noticed, network drives connected in one context are not visible in the other. The problem is that GPO-based login scripts are being executed in the Administrator context – not the ordinary user context.

So, how do we get it working? Microsoft offer an unsupported kludge in KB937624 – getting around the issue by weakening Windows security and forcing network connections to be common to both user contexts. They carefully designed this not to be the case, so modifying the behaviour does seem like a bad idea.

However, Microsoft’s preferred solution (example launchapp.wsf script in the appendix of that page) is to use the GPO-triggered script to set a Scheduled Task to run immediately in the other (non-admin) context, and run your login script from there – much better.
The reasons I’m writing all this up are that:

Microsoft’s example script has some illegal character/line-wrap in there – copying and pasting it won’t work!

This method doesn’t work with XP so some forking logic is needed if you have mixed clients.

They make no allowances for multiple admin/non-admin users sharing the same PC.

This appears to be Microsoft’s sole example document of how to program using the Task Scheduler 2.0 API, and it neglects to define several absolutely essential object properties if you want to do something more useful than simply open Notepad.

My particular problem was that I needed to launch a script with a space character in the path, e.g.:

For me changing this path name was not an option as there were many other dependencies. I spent a long time wondering why the API was eating my quotes as I fed it the above string and I tried various ways to escape them. Eventually I launched the Scheduled Tasks MMC tool (click on the root of Task Scheduler Library to see the job). Looking in the Action properties I realised that there are separate fields for the starting directory and for the arguments. Manually editing the job to use these got it working:
Frustratingly, there don’t seem to be any examples on the Web showing you how to populate these fields programmatically. Guessing the Arguments property was straighforward but StartIn is not a valid propery name. I read on Wikipedia that Task Scheduler 2.0 uses XML to store its jobs so I exported the job and viewed it. Luckily they used consistent property names in the XML (Arguments and WorkingDirectory) and I was able to set them in VBScript (see highlighted lines below).

There was an additional complication though. Once a user has run the Scheduled Task, it’s left behind on the system. In my initial testing this wasn’t a problem because I was testing admin users, but I soon discovered that a non-privileged user cannot delete and recreate the task if one created by another user already exists. So we need only schedule the task if the current user is running in an elevated security context. By far the simplest method is to parse the output of the whoami /groups command, as explained in this post:http://blogs.technet.com/b/jhoward/archive/2008/11/19/how-to-detect-uac-elevation-from-vbscript.aspx

UPDATE – added some logic to prevent the login script from launching for RemoteApp sessions to Terminal Servers.