Group Policy

Deploying Printers In Windows 10

Printers are pretty easy to deploy via Group Policy. It’s easy to configure a Group Policy Preference to deploy a printer, but there’s a few gotchas that may prevent the printer from actually getting installed client side.

The first thing to check is Event Viewer > Applications. If Group Policy attempts to add a printer but fails, it should be logged as a warning and give an idea on what the problem is. If you’re stuck – enable Group Policy Preferences Logging and Tracing for Printers, and see if you get more data.

For Windows 10, depending at what patch level you’re at, and what drivers the print server has, and if those drivers are packaged or not you’ll probably have to enable more policies to make printers deploy. If you don’t, you may see this error in Event Viewer: “Group Policy Object did not apply because it failed with error code ‘0x80070bcb The specified printer driver was not found on the system and needs to be downloaded.’ ”

There’s a lot of information out there on this topic – but generally, the main reason a printer won’t automatically install is because of UAC. If you try to manually install one of these printers, you’ll get the ‘Do you trust this printer’ warning, and even after continuing on that, the install may fail.

There’s two Group Policies to configure to get around this, which I found blogged at Systemcenterdudes so please read their post – but you need to enable these two policies:

Computer Configuration > Policies > Administrative Templates > Printers – Package Point and Print

Computer Configuration > Policies > Administrative Templates > Printers – Point and Print 

In both of the policy settings, you may need to specifiy your print servers. It wouldn’t work for me until I did – and it’s a better security approach to do this anyway.

Once that was done, printers were then able to be installed automatically via Group Policy. There’s some other ways I’ve read to change how the drivers work, push out registry fixes etc – but to me this seems the simplest and safest approach (assuming it works for you too!).

If you’ve had a different experience or the above doesn’t work, please share!

Hide Edge Button from IE11 Tab

A feature that’s popped up in IE11, is the little Edge icon next to the new tab icon. Not something I’d want in the enterprise space:

Thankfully, it’s easy to disable. There’s a group policy policy called “Hide the button (next to the New Tab button) that opens Microsoft Edge” which can be found in User Configuration\Administrative Templates\Windows Components/Internet Explorer\Internet Settings\Advanced Settings\Browsing\ . 

If you can’t see this policy, make sure you have the latest ADMX files from Microsoft – Windows 10 1703. If you haven’t had much to do with adding ADMX files to your environment before – they should be centralised, and Microsoft have a great guide you can follow.

Bonus tip – If you have internal sites that use a single word (e.g. intranet) you can enable the policy “Go to an intranet site for a one-word entry in the Address bar” which will check for an internal site starting with that name before using the word in your default search engine. This one’s actually an old policy that I hadn’t noticed before!

Group Policy Preferences – Replace Existing File

I’ve written before on how great Group Policy Preferences are, and thought I’d write a quick ‘how to’ on a likely common scenario – replacing an older file with a new one, but only if it already exists.

Pushing out a file via Group Policy Preferences is quite easy and has been around for a long time.

When creating a new file rule, you’ll see 4 options under ‘Action’ – Create, Replace, Update and Delete:

gpp2

Create will only copy the file from the source to the destination if the file doesn’t exist at the destination
Replace will actually remove a file (if one exists), and copy the source to the destination regardless if a file existed or not
Update is the misleading one, it will modify the file attributes of the destination file to match the source – if the files themselves are different, it won’t copy them. If the file doesn’t exist, it will copy the file to the destination though!
Delete will delete the file(s) specified.

None of these provide a solution to ‘Replace file only if it exists’ though. There’s two obvious ways this can be achieved; you can use ‘Replace’ but this will continually replace the file every time Group Policy is run, which in the user context is every 90 minutes. You also can’t use the option ‘Apply once and do not reapply’ because it will run regardless of the file existing or not – which means if the file isn’t there before group policy runs, the file may be replaced by a software install or other mechanism, and with the order out of whack, resulting in the wrong file being left there in the end.

The next logical way to make sure the order is correct is to use Item Level Targeting. Under the ‘Common’ tab, you can tick the box for ‘Item Level Targeting’ and point to the file in question:

gpp3

This will only run once though, and that is regardless of the ‘Item Level Targeting’ being true or false. That only controls whether the policy does what it’s configured to do, at the client side it’s still ‘run’ the policy, it just had nothing to do.

thommck had the best answer on how to get around this that I’ve found – use a custom WMI query. You’ll need to remove the ‘Apply once and do not reapply’ tick, but the file itself will only be copied over when both targeting rules are true. Please read his post for all the details, but the second item will need to be a WMI query, and have a string similar to this:

SELECT LastModified FROM CIM_DataFile WHERE name=”C:\\windows\regedit.exe” AND LastModified < ‘20160701000000.000000+060’

(Update 20th September 2024)

jszabo_98 in the comments has mentioned that he had to make a few small changes to the above WMI query example to work:
get-wmiobject -query ‘SELECT LastModified FROM CIM_DataFile WHERE name=”C:\\windows\\regedit.exe” AND LastModified < “20160701000000.000000+060″‘

(End of update)

This is checking the date of the file, and will only be ‘true’ if it’s less than that date.

Keep in mind that this is less than ideal, as WMI queries aren’t the most efficient way of processing group policy preferences, but it may be better than copying files around your network to every PC, every 90 minutes.

Search Group Policy with PowerShell Script

I was looking for a certain Group Policy Preferences setting, where a registry value was being changed. Resultant Set Of Policy (RSOP) won’t help with these, and I couldn’t see a nice PowerShell command for searching through Group Policies.

I put the shoutout on Twitter to see who could help, and Tony Murray came back quickly with a script he’d created, and promptly uploaded to the Microsoft TechNet Gallery where I could download it.

It’s a reasonably simple script (which for me would have taken at least an hour to do beginning to end!) and is very easy to use.

Running the ps1 file will provide you with a prompt, asking what string you’re searching for. Enter the string, and it’ll give back all the Group Policy objects, along with if there was a match or not:

match

After seeing it work, I decided to make one slight change; I removed this section:

    else { 
        Write-Host "No match in: $($gpo.DisplayName)" 
    } # end else 

which results in the script only showing matches, and displaying no output otherwise. Handy if you have a long list of objects to look through!

Thanks again Tony for both writing this and sharing it!

 

Update 20th Dec 2018

Although the script is really useful, it didn’t like special characters for the search string which makes it hard to search for registry settings. I’ve changed how the search function works on a single line, and it now seems to be happy with special characters. This also appears to come at a cost of speed, it’s a bit slower to search. I’m letting Tony know so he can consider updating his master script, but if you want to do it, just replace the line:

if ($report match $string) {

with

if ($report.contains(“$string”) -eq $true) {

Again since it’s not my script I don’t really want to put the entire end result up, but here’s how it should look after the comments section: