Adding 32-bit print drivers to 64-bit print server
This is one of those issues that I just can’t figure out why Microsoft did not include both 32-bit and 64-bit print drivers on the media for Windows Server 2008. Or maybe as a download pack or something. The trend is definitely to use 64-bit servers (no other choice if you’re using Windows Server 2008 R2 or newer), but many client workstations are going to be 32-bit for years to come. Anyhow…if you have a 64-bit print server and need those 32-bit print drivers, see below. (Or vice versa, 32-bit print server serving up print queues to 64-bit workstations).
Step 1: Share a print queue out on the 64-bit print server
- Login with local administrative permissions to the Windows Server 2008 64-bit print server.
- Add a new printer, name it, share it, add to the directory, etc. (You should be using the Print Management Console to manage your printers!)
At this point you have a new shared print queue with 64-bit drivers.
Step 2: Add the 32-bit drivers
- Login with local administrative permissions to a Windows Server 2008 32-bit server. (For best results always use the EXACT SAME OS VERSION AND SP LEVEL here, though you can possibly do this from a fully up to date Windows 7 or Windows Vista workstation)
- Browse to the 64-bit print server by UNC path, i.e. \\PrintServer.
- Click on the Printers folder (or just include that in your UNC path above).
- Right-click a shared printer and select Properties from the context menu.
- Click on the Sharing tab.
- Click the Additional Drivers button.
- Check the x86 Type 3 - User Mode box.
- Click OK, install the drivers.
- Close all open windows.
Done.
Adapted from TechNet social discussion.
AD Powershell cmdlets!
With the release of Windows Server 2008 R2, there will finally be native support for Active Directory management in Powershell. For those of us (myself included) who don’t/won’t use the third-party add-ins for AD, this is great news!
Check out the AD Powershell team’s blog: Active Directory Powershell Blog (easy enough name to remember) for more information and a downloadable cmdlet reference chart.
Thanks AD Powershell Team!
Windows Update error 80072F78 in Windows Server 2008
Although I haven’t actually found the exact cause (and thus the solution), I’ve run across problems using Symantec Endpoint Protection (i.e. Symantec Corporate 11.0) on Windows Server 2008. It seems that something in the protection configuration in the Symantec product is blocking Windows Updates. You’d get the error code 80072F78 and no updates.
Uninstalling version 11 and moving back to version 10.2 allows Windows Updates to be performed again, although I’m not sure yet what the real issue is or how to fix it. Anyone else run across this?
Update 2/20/2009: This may be the solution, though I’ve not tried it.
Scripting backups of AD LDS (ADAM) with dsdbutil
Although I’ve worked with Windows Server 2008 for quite some time now in test, I’ve just recently deployed the first production server into our environment. This was to be a replacement for an ADAM (Active Directory Application Mode) development server used by the applications team. The server itself is a VM running Windows Server 2008 since the requirements of ADAM (now known as Active Directory Lightweight Directory Services in Windows Server 2008) are minimal from a performance standpoint.
Given the changes in how Windows Server Backup works in Windows Server 2008 (you cannot select just a part of the system volume to be backed up and you need a dedicated drive for backups to be stored on, by default), I was not looking forward to using it to get backups of the AD LDS databases. Since the adamntds.dit files are open all the time, they’d need to be backed up by a normal backup program using Volume Shadow Copy. Windows Server Backup would fill that need, but at the cost of backing up the entire system volume (over 9 GB), so that’s really a waste of space and effort. Since we use Tivoli Storage Manager (TSM) as our enterprise backup/restore/disaster recovery solution, using Windows Server Backup to backup the entire server just seemed silly. Of course, the problem with TSM is that considers .dit files to be off limits by default except when backing up the System State on a Domain Controller, so even using TSM’s open file support, I could not get a backup of the adamntds.dit files. Bummer. Enter the dsdbutil command.
You can schedule scripted backups of your AD LDS instances databases using the dbdsutil command easily enough, although at first glance at the relevant documentation this is definitely not the case. (See the relevant TechNet article here.) Like most other context sensitive commands, you can simply string together all of the commands you want to execute. So instead of you entering them manually one at a time as the TechNet article implies, you can just concatenate them all on one line and sit back and enjoy your quick and easy AD LDS instance backups.
So, the sample batch file you would use in your scheduled task would look something like this:
rd C:\ADLDS_BACKUP /Q /S
dsdbutil “activate instance INSTANCE1” ifm “create full C:\ADLDS_BACKUP\INSTANCE1” quit quit
dsdbutil “activate instance INSTANCE2” ifm “create full C:\ADLDS_BACKUP\INSTANCE2” quit quit
Note that’s only three lines of code there to backup two different instances (I’ve put line breaks in between each line). When using the dsdbutil command to create the ifm (install from media) backups, the destination directory must be empty, thus the usage of the rd (remove directory) command first in the batch file. You will want to schedule this task to run using an account that is a local administrator, and be sure to select the task to run with highest privledges or else you won’t get the directory removal you need.
-
Translator
