Just saw this note whilst browsing the help on Drive Maps in Group Policy Preferences:
You can use a Drive Map preference item to configure the visibility of a physical drive rather than a mapped drive. To do so, select the Update action, leave the Location field blank, select the drive letter of the physical drive, and then configure the Hide/Show this drive and Hide/Show all drives options.
So, to hide “A” drive (in this example), you’d configure the dialog box as follows:
I didn’t know this was possible. This may come in handy one day, if you want to hide something like an OEM partition that has had a drive letter assigned.
Another printing-related issue I experienced this week was as follows:
- I set up some new printers on the print server, and shared them out
- I then used Ricoh’s “Default Editor” application to lock down the colour printing options
- When attempting to map these printers from a workstation, the user experienced an “Access Denied” error, and the printer would not be connected
I left the problem overnight, and luckily had a brainwave; maybe it was something to do with permissions on the driver files themselves on the print server? Sure enough, resetting the permissions on child items within the %systemroot%\system32\spool\DRIVERS\w32x86 folder solved the problem.
Had a problem today where a printer driver became corrupted on our print server. This, in turn was causing the Print Spooler service on the workstations to crash repeatedly. I was unable to delete the mapped printers through the normal Printers and Faxes/Printers/Devices and Printers interface because the spooler kept crashing.
As part of the investigation process, I first used Group Policy Preferences to set the recovery options for the Print Spooler process on each workstation to always restart:
The resolution for the problem is quite a brute-force solution as the problem was confined to only a few workstations. If the problem had been more widespread, I would have narrowed down which dll was causing the problem, and then removed it via GPP using the “Apply once and do not reapply” option or via a PowerShell script.
What I then did was re-install the latest printer drivers for each of the printers that I suspected to be the cause of the problem. This is done on the print server by going to Control Panel, Printers and Faxes, File menu, Server Properties, Drivers tab. You can then select the printer driver in question and click the Reinstall button.
The solution on each workstation was as follows:
- On the local workstation, start a command prompt as Administrator (Start, “cmd”, ctrl+shift+enter). Enter your admin credentials.
- Go to c:\Windows\System32\spool\drivers\w32x86\3 (this applies to 32bit Windows/drivers only)
- Delete all files within the above folder (del c:\Windows\System32\spool\drivers\w32x86\3\*.*)
- Restart the spooler. If you don’t do so, you’ll experience errors about Windows being unable to locate the correct driver (net start spooler)
- That’s it. Close the command prompt window (exit)
Go to Start, Printers, and verify that they’re all there. The Print Spooler service should no longer crash upon viewing the mapped printers. Some printers may have a status of “opening” for a while as they need to re-download their drivers from the print server.
If you need to make a test connection to a MS SQL DB as a different Windows user, and you’re not using SQL authentication, you can do the following:
runas /user:domain\sqluser "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
You’ll then see the following messages after being prompted for a password for that user:
Attempting to start C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe as user "domain\sqluser" ...
Creating my first Powershell script, I came up against code execution issues. Rather than take the easy (sketchy) way out and simply enable execution of unsigned code, I went and figured out how to sign my scripts using my internal CA. Powershell’s internal help is very useful also:
My CA is (still) a Windows Server 2003 DC, so that’s what this is based on.
- Connect to your CA using the Certification Authority snapin, and ensure that the Code Signing certificate template is enabled/loaded. If it isn’t, just right-click on Certificate Templates and select New –> Certificate Template to Issue
- Ensure that HTTPS is enabled for your CA’s Certificate Services virtual directory, and then navigate to it using IE from your own PC;
https://{CA-name}/certsrv
- Go to Request a certificate, User Certificate (click Yes, to any IE popups at this point), go to More Options >>>, Use the Advanced Certificate Request form, select the Code Signing certificate template, and then Submit your request.
- Once your certificate is issued and installed, you’ll be able to view its details using this Powershell command:
Get-ChildItem cert:\CurrentUser\My -codesigning
- Sign your Powershell script with the following command. I ran into an issue where I received an “Unknown Error”, but this turned out to be because I had created the script from within the Powershell ISE. This handy blog post helped me out.
Set-AuthenticodeSignature .\{script name}.ps1 @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0]
There’s some pretty useful info here, on powershell.com
