It is important to get the network card configuration right in the parent partition for Hyper-V in Windows Server 2008/R2.
Common problems include:
- A-Records and PTR’s registered for the Parent Partition under multiple IP addresses
- NetBIOS conflicts
- Unwanted traffic going through network cards that you want to dedicate to, for example, VM’s or iSCSI.
These problems have nothing to do with Hyper-V actually. They’re just issues you can face with any server containing more than one network card.
Step #1: Ensure that you have a good naming convention for you network cards
As you can see I have explicitly named by network cards. One for the parent partition, one for the VM’s. If you have one or more network cards for VM’s or iSSCI, name them accordingly.
Step #2 : Ensure that the parent partition uses the right network card
In the image below you can see that the Parent Partition network card is first in the order. This means that network services will attempt to use this interface before the VM NIC #1.
Step #3 : Ensure that the VM or iSCSI NIC does not register itself in DNS
Make sure that the network cards you dedicate for VM external networks do not register themselves in DNS. Just configure the basic IP address and mask. You do not need to include DNS servers etc. Remember, you are more or less turning this network card into a virtual switch.
Note that the “Register this connections addresses in DNS” is left un-ticked. If you built you base OS for the parent partition with all the network cards patched, chances are that you will find more than one address registered for the server in DNS. Ensure that you remove unwanted A-records and PTRs.
Step #4: Ensure that you disable NetBIOS over TCP/IP on the VM network cards
I was recently asked a question about PowerShells ability to read in an XML configuration file at a Virtual Academy I ran last week. One of the strengths of PowerShell is its ability to perform lots of time saving tasks … one of which is reading in an XML file. The Get-Content command can read in an XML file and you can easily loop through the contents.
Example:
[xml]$computerlist = Get-Content computers.xml
foreach( $computer in $computerlist.computers.target)
{
Write-Host $computer.name
}
What would the XML file look like?
<computers>
<target>
<Name>server1</Name>
</target>
<target>
<Name>server2</Name>
</target>
</computers>
Nice and simple really.
“Although bulk deletions are rare, they are disruptive events that you can guard against by removing the Delete and the Delete Subtree permissions in Active Directory. To guard against accidental deletions, you should remove the Delete and Delete Subtree permissions on organizational units (OUs) that contain user accounts, computer accounts, and security groups in Active Directory. You should also remove the Delete All Child Objects permission on the parent container of an OU that you want to protect.”
This above is taken from http://technet.microsoft.com/en-us/library/cc773347(WS.10).aspx
The TechNet article then shows you how to manually, through the GUI, modify the access control entries (ACE’s). You can find details here.
So, how do you go about this task if you have quite a few OU’s? You need the following from the Windows Server 2003 Support tools:
dsquery will, by default, only return the first 100 results. You’ll need the ‘–limit 0’ to process more than 100 objects, in this case OUs.
To protect all OU’s in a domain run the following:
for /F "tokens=*" %%i in ('dsquery OU -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"
To protect a specific OU and all leaf OU’s:
for /F "tokens=*" %%i in ('dsquery OU “ou=target,dc=domain,dc=net” -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"
To revert the all OU’s ACE’s back to the Schema default:
For /F “tokens=*" %%i in ('dsquery OU –limit 0') do dsacls %%i /S
Life is much easier in Windows Server 2008. By default the containers are protected from accidental deletion.
With the economic down turn and the green agenda Virtualisation has become a hot topic with my customer. These days its all about getting the best value for money as possible with your IT budget, so when my customer had a number of servers out of warranty and due for replacement the Hyper-V platform was the first port of call.
The first thing we did was run the Microsoft MAP tool against these servers to ensure that they were real candidates for Virtualisation. This tool can be found at
http://www.microsoft.com/downloads/details.aspx?familyid=67240B76-3148-4E49-943D-4D9EA7F77730&displaylang=en
Information on using the tool can be found at
http://technet.microsoft.com/en-us/library/bb977556.aspx
Currently my customer has a number of Hyper-V GEO Cluster's based on HP boot from SAN Blades. All of the Virtual Hosts are managed centrally by Microsoft System Centre Virtual Machine Manager (SCVMM). Using the map tool we were able to determine that based on the existing hardware we could achieve an 8 - 1 virtual machine ratio. Considering that the new hardware runs cooler / cheaper and is only a couple of U per blade compared to the 6 - 8 U servers they were replacing everyone was happy.
All of the machines to be Virtualised were Windows 2000 & ran bespoke applications. If we were to rebuild these servers on new kit it would have taken a lot of time and effort to ensure that the applications were tested etc.. not to mention the downtime involved.
Pre-Requisites
You will need the following patches on the Hyper-V target systems.
KB950050, KB951308, KB956589, KB956697, KB956710, KB956774
You will need the following patch on the SCVMM Server
KB959596
You will also need the following version of WAIK for all offline conversions. The version included with the OS will not do the job. Install this on the SCVMM Server.
http://www.microsoft.com/downloads/details.aspx?familyid=C7D4BC6D-15F3-4284-9123-679830D629F2&displaylang=en
Using the P2V Wizard
In this example I am performing a physical to virtual conversion on a Windows 2000 server.
A Windows 2000 server P2V has the following pre-requsites.
- Service Pack 4
- 512MB RAM minimum
As the source service is Windows 2000 the only option is an offline conversion. As part of the process an agent will be installed on the source server and the server will be re-booted into WinPE so that the contents of the source servers hard drive can be copied via BITS.
1. With the Virtual machines menu option high lighted click on Convert Physical Server.
2. Enter the Computer name or IP address of the Physical Server and account details of a user that has local administrator rights on the source Physical Server.
3. Enter a Name for the New Virtual Server. Set the owner of the Virtual Machine (defaults to the logged in user) and add a description for the Virtual Server.
4. Click Scan System to install the SCVMM agent & gather information on the Physical Server.
5. After the scan the System Information panel will be populated. Click Next to continue.
6. Here we select the volumes to be copied to the new VM as part of the P2V process. You can also change the VHD type from Dynamic to Fixed.
7. Typically on this screen I choose to obtain an IP address automatically from DHCP. You can specify an IP address & Network card (using MAC address) if required.
8. On this screen you can specify the number of process and amount of RAM the VM will use. I usually set the VM to use 2 processors during the P2V process. This helps with the integration components setup, it can be changed back to a single processor later. Please note that these settings will be used to determine the placing of the VM on a host server as we will see later.
9. Here you choose the server that will host the VM. You can see the suitability of each host based on the Star Rating. This is much improved when SCOM is used in conjunction with SCVMM. In the screen shot below SCOM was not configured.
10. As the host I selected was a Windows 2008 Hyper-V cluster I got this message box popping up. Click Yes to continue. SCVMM will set up the new virtual server as a clustered VM.
11. Select the volume that the VM will reside on. If your target volume does not appear on this list refresh the cluster information within SCVMM.
12. Select the Virtual Network that the Virtual Machine will use.
13. As this VM will reside on a cluster do not change these settings. This allows the cluster service to manage the Virtual Machine.
14. If all is ok you should see this screen. You can run into an issue that can occur with legacy hardware (i.e. RAID controllers) not included with the WINPE Image, which is used to boot into the P2V environment . If you can obtain the Vista driver for the problem hardware copy it to SCVMM\Drivers\Import folder to solve the issue.
15. This last screen gives us a summery of the P2V job & the option to View and copy the PowerShell script generated by the wizard. You can copy out this script and modify it for automating this process if required.
16. After clicking Create the jobs screen will pop up. This screen provides real time information regarding the P2V process including the time required to copy the contents of the targets volumes to the new virtual machine.
17. Here we can see the BITS copy in progress and the amount of time remaining to copy the volumes.
18. The script we created with the Wizard also installs the required virtual machine components. In some cases this process will seem to hang. This can be resolved by using the Hyper-V console on the target machine to re-start the VM.
20. Once the jobs screen completes we will have a running Windows 2000 VM. Check that the VM is running on the External Virtual Network and that the source machine is turned off and removed from the Network.
The process was quick with minimal downtime for the users. We did run into some issues with legacy RAID controllers but got around them using the fix mentioned in step 14. The new VM’s are a lot more stable than the previous hardware and are now on a high availability platform giving my customer more peace of mind.
One of the most common conversations I have about virtualisation is the "how do I make my virtual machines highly available?" one. Topics like Hyper-V Quick Migration are then discussed and off the techie goes to start testing. When I revisit the discussion I have noticed the false sense of security people get just because their virtual machines are highly available. HA options for VM's do not mean stop worrying about host clustering, network load balancing or traditional backups ... no matter how clever the technology. Highly available virtual machines no longer have the single point of failure at the (host) hardware level .. and that's about as far as it goes. You still have to mitigate against the same risks at the OS level (and above) regardless of whether or not its physical or virtual. Okay, some of you are saying duh! Bear with me though. It's not uncommon for people to think just because they have a Hyper-V cluster or VMWare HA that the majority of potential outages are accounted for.
Consider the following:
- Most HA options will require that the host(s) is/are functioning correctly. If you have problems with the host, expect problems with your HA solution.
- Replication of virtual hard disks will not protect you from data loss or corruption inside VM. The loss will be replicated.
- Replication of virtual hard disks will not protect against corruption of virtual hard disks or settings. The corruption will be replicated.
- Live migration options really only work for planned downtime. Unplanned downtime will result in your VM's being restarted with a (varying) loss of service.
With the above in mind, have a read of the following:
Long story short, virtualisation has not changed anything when it comes to mitigation against system failure/outage. The same rules still apply. Virtualisation high availability solutions represent only the first layer of protection .. just don't forget the other options like:
- Traditional Backup and Recovery
- Host Clustering
- Network Load Balancing
We are running an event this December for Microsoft Premier customers. I'm pretty excited about it actually. Premier Field Engineering and Microsoft Consulting Services are teaming up to present real world details on Hyper-V, System Centre Virtual Machine Manager 2008 and Application Virtualisation. We plan on running as many demonstrations as possible during the event so death by PowerPoint should not be an issue.
This event is only open to Microsoft Premier Customers. Contact your Technical Account Manager to reserve your place. If you are not a Premier Customer we plan on running the event again early in 2009. Drop me an email if you are interested in attending.
Here is the agenda for the event :
Title: Technology Day – Microsoft Virtualisation (Level: 300)
Location
Microsoft Sandyford
Building 3, (Atrium B)
Carmenhall Road,
Sandyford Industrial Estate, Dublin 18
Training Room 5.41
Date & Time
Fri 5th December @ 9:15
Breaks
15 mins @ 11:15 am
1 hour @ 1pm – 2pm (Lunch)
15 mins @ 3:30pm
Morning
09:30
Workshop Introduction
09:45
Microsoft Virtualisation @ Nissan Ireland
Rory Donnelly (CIO Nissan Ireland)
10:00
Virtual Data Centre :
Microsoft Server Virtualisation and System Centre Virtual Machine Manager
Gavin McShera, Victor Arzate Rodriguez and David McCormick
This session is aimed at providing skills to deploy and administer a Virtualised Data Centre, using Microsoft Server Virtualisation products and System Centre Virtual Machine Manager 2008.
Content:
Hyper-V Architecture
- Understand the architecture behind Windows Server 2008 Hyper-V and Hyper-V Server.
- Learn how to increase uptime, by understanding what is happening under the covers of Hyper-V.
Getting to grips with Server Core Hyper-V and Hyper-V Server
- Understand the process of enabling Hyper-V on Server Core including enabling remote management.
- Understand the best practices for management and delegation.
- Learn from our experience of deploying Hyper-V Server Core.
Performance Best Practice & High Availability
- Understand Hyper-V Performance Best Practices – The big 4: Disk, Memory, Network & Processor.
- Understand Failover Clustering Best Practices, Server Core hosts & Management.
Managing Hyper-V
- Learn how to effectively manage Hyper-V hosts in an enterprise deployment using SCVMM 2008.
- Understand SCVMM design considerations and best practices.
Deploying and Migrating to Hyper-V
- Understand various methods of virtual machine deployment, including with SCVMM 2008.
- Learn about some common migration routines.
Afternoon
02:15
Application Virtualisation with Microsoft App- V (formerly Softgrid)
Alan Stone and Paul Devlin
This session introduces Microsoft Application Virtualisation and provides notes from the field with real world scenarios
Content:
- An overview of the App-V technology
- How App-V can mature the IT Environment
Notes from the Field
- How App-V helped a customer overcome application delivery challenges
- Benefits to mobile workers
- Application Compatibility
- Sequencing Recipes best practices
Application Virtualisation 4.5 What does the future hold?
- Integration with the System Centre family of products
- New Deployment methods for Virtualised applications
- Asset intelligence & App-V 4.5
03:45
Open Discussion – Q & A
Single Sign On for Windows XP Clients
Single Sign On (SSO) to Windows Server 2008 (W2K8) Terminal Services uses the Credential Security Service Provider (CredSSP). CredSSP delegates credentials to defined target servers and is native to Windows Vista. Windows XP SP3 includes CredSSP but it is not enabled by default. Windows XP SP2 clients can still connect to W2K8 Terminal Services but users will be prompted for credentials upon establishing the first session. Having to enter your username and password ruins the RemoteAPP experience. So what do you need to get your Windows XP client seamlessly connecting to a W2K8 Terminal Server?
- Windows XP SP3
- Remote Desktop Connection (RDC) 6.1 (Part of SP3)
KB951608 explains the CredSSP for Windows XP SP3 in detail.
Once you have SP3 installed you need to make the following changes:
Client side:
- Enable CredSSP
- Configure Single Sign On for credential delegation
- Define target servers
Server side:
- Modify RDP protocol settings
Enable CredSSP
The CredSSP settings have to be APPENDED to the existing parameters. See KB951608. Appending to existing keys could prove time consuming if you have a lot of clients. Here is a script written in VBS that may make automating the task a little easier.
Disclaimer: Do not blindly run these scripts without testing first. Make sure you take a backup of the registry!
Const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
‘strKeyPath = "SYSTEM\CurrentControlSet\Control\Lsa"
strValueName = "Security Packages"
oReg.GetMultiStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,arrSecurityPackages
For Each strValue In arrSecurityPackages
if lcase(strValue) = "tspkg" then intTSPKG = 1 ‘ Set a flag to say that value already exists
Next
if intTSPKG <> 1 then ‘Value doesn’t exist so lets create it
intNewArraySize = Ubound(arrSecurityPackages) + 1
reDim Preserve arrSecurityPackages(intNewArraySize) ‘Resize the array for new value and keep existing values
arrSecurityPackages(intNewArraySize) = "tspkg" ‘ Add the new value
oReg.SetMultiStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,arrSecurityPackages
End if
strKeyPath = "SYSTEM\CurrentControlSet\Control\SecurityProviders"
strValueName = "SecurityProviders"
oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
intResult = InStr(strValue, "credssp.dll") ‘Will return position found in string
if intResult = 0 then ‘Position of 0 means string not found
strValue=strValue & ",credssp.dll"
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
End if
Configure Single Sign On and define target servers
The following registry changes enable CredSSP for the default credentials.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]
"AllowDefaultCredentials"=dword:00000001
"ConcatenateDefaults_AllowDefault"=dword:00000001
The following registry changes define the target servers.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials]
"1"="TERMSRV/*"
You can explicitly name your terminal servers e.g. :
- TERMSRV/myserver.mydomain.com : A specific server
- TERMSRV/*.mydomain.com : All servers in mydomain.com
- TERMSRV/* : All servers
RDP Protocol changes
You have to make some changes to the default RDP protocol settings on your server in order to allow Windows XP SP3 clients connect.
Open Terminal Server Configuration snap-in and modify the RDP connection properties as follows:
Note that the tick has been removed from the "Allow connections only from computers running Remote Desktop with Network Level Authentication". I have the Encryption level set of Client Compatible but there is no reason why you cannot use High.
Make sure that the Use client-provided log on information radial button is selected.
You should now be in a position to make use of the SSO functionality from your Windows XP clients. However, there is a KB titled When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server which comes with a patch. During my testing I did not come across this problem ... but I figured it was worth noting.
Over the past week or so Microsoft have clarified the support statement for server products running in virtual environments. The most significant announcement was the Server Virtualisation Validation Program (SVVP). To quote "The Server Virtualization Validation Program (SVVP) is open to any vendor who delivers a virtualization machine solution that hosts Windows Server 2008, Windows 2000 Server Service Pack 4 and Windows Server 2003 Service Pack 2 and subsequent service packs. The virtualization solution can either be hypervisor-based or a hosted solution. The program enables vendors to validate various configurations so that customers of Windows Server can receive technical support in virtualized environments. Customers with validated solutions will benefit from the support provided by Microsoft as a part of the regular Windows Server technical support framework."
The participating vendors (at time of writing are):
- Cisco Systems, Inc.
- Citrix Systems, Inc.
- Novell, Inc.
- Sun Microsystems
- Unisys Corp.
- Virtual Iron Software
- VMware, Inc.
The SVVP does not mean that Microsoft support the products from the vendors listed above. The SVVP means the validated third party product provides a suitable environment upon which the Microsoft operating system can run. If you think about it, the SVVP is very similar to the hardware certification for Microsoft operating systems.
Now that you know the supportability of your Microsoft operating systems turn your eyes to the support statements for Microsoft server software. Microsoft server software and supported virtualization environments.
You'll find statements for :
- Microsoft Application Virtualization (App-V)
- Microsoft BizTalk Server
- Microsoft Commerce Server
- Microsoft Dynamics AX
- Microsoft Dynamics CRM
- Microsoft Dynamics NAV
- Microsoft Exchange Server
- Microsoft Forefront Client Security
- Microsoft Intelligent Application Gateway (IAG)
- Microsoft Forefront Security for Exchange (FSE)
- Microsoft Forefront Security for SharePoint (FSP)
- Microsoft Host Integration Server
- Microsoft Internet Security and Acceleration (ISA) Server
- Microsoft Office Groove Server
- Microsoft Office PerformancePoint Server
- Microsoft Office Project Server
- Microsoft Office SharePoint Server and Windows SharePoint Services
- Microsoft Operations Manager (MOM) 2005
- Microsoft Search Server
- Microsoft SQL Server 2008
- Microsoft System Center Configuration Manager
- Microsoft System Center Data Protection Manager
- Microsoft System Center Essentials
- Microsoft System Center Operations Manager
- Microsoft System Center Virtual Machine Manager
- Microsoft Systems Management Server (SMS)
- Microsoft Visual Studio Team System
- Microsoft Windows HPC Server 2008
- Windows Server 2003 Web Edition
- Microsoft Windows Server Update Services (WSUS)
- Windows Web Server 2008
Licensing changes:
There are plenty of posts on the interweb that show you how to mount and unmount vhds via powershell. I downloaded the Hyper-V PowerShell management library from CodePlex.com here as created by James O'Neil. In it he kindly provides two scripts (mount-VHD.ps1 and Unmount-VHD.ps1) along with a REG file. Assuming you have PowerShell 1.0 installed (available feature in Windows Server 2008) these scripts and registry settings work fine.
I ran into problems once I downloaded and installed the Windows PowerShell 2.0 Community Technology Preview (CTP). Powershells execution policy wouldnt let the scripts run anymore.
You can change the executionPolicy a number of ways:
Registry:
HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
Change the key: REG_SZ ExecutionPolicy to Unrestricted
PowerShell:
set-executionpolicy unrestricted
Note: By changing the execution policy you are technically opening your system up to remote execution of PowerShell scripts from unsigned/untrusted sources. I want to be able to mount vhds easily coz Im a lazy kinda guy. Im running Hyper-V on my laptop so Im not too concerned about security in this instance. You should think carefully about making this change in a production environment.
The second thing I noticed was that the registry settings provided by James no longer worked. So I came up with a slight modification as follows:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Virtual.Machine.HD]
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\DefaultIcon]
@="%SystemRoot%\\system32\\imageres.dll,26"
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell]
@="Mount"
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Mount]
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Mount\command]
@="cmd /k \"powershell -NoProfile -Command \"& 'c:\\Program Files\\Hyper-V\\Mount-VHD.ps1' '%1'\"\""
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Unmount]
[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Unmount\command]
@="cmd /k \"powershell -NoProfile -Command \"& 'c:\\Program Files\\Hyper-V\\Unmount-VHD.ps1' '%1'\"\""
[HKEY_CLASSES_ROOT\.vhd]
@="Virtual.Machine.HD"
I've used cmd/k instead of cmd/c so I can see what the PowerShell script reports when its finished along with a couple of changes to get PowerShell to accept the string after the -Command.
Now all is great in the land of Hyper-V on my laptop.
Where is the cluster log in Windows 2008 ?
This short answer is its no longer there. On our Windows 2008 cluster node if we navigate to %systemroot%\system32\LogFiles\Cluster your wont find the cluster.log file anymore.
Why ? Its been replaced by a much more sophisticated event based tracing system.
The Vista\Windows Server 2008 Event Model is the next generation of Windows Event Logging and replaces the current version of the Event Log shipped in Microsoft® Windows® 2003 Server, Microsoft® Windows® XP, Windows 2000, and previous versions of Microsoft® Windows NT®.
The new model is a major update to the NT Event Log service. It maintains 100% backwards compatibility with the existing APIs and functionality and fully leverages the existing NT Event Log instrumentation in the applications and services. At the same time, it eliminates some of the limitations of the NT Event Log and provides additional features to better support monitoring and diagnostics of Windows applications, services, components, and drivers.
In a future post I will go through the new Logging and tracing features for clusters in Windows 2008 but for now lets look at how to get access to the old familiar cluster.log file.
Here's how to go about it.
1. Go to a command prompt
2. Type "Cluster /Cluster:yourclustername log /gen /copy "C:\temp". You should get output as follows
3. Navigate to the c:\temp directory and there you will find the .log files for each node of your cluster.
The cluster log can now be opened in Notepad.
Please note that you need to run this command after each change as its not dynamically updated like the old .log file.
This is a not so common issue I can across this week . The background is as follows.
- You decided to evict a node from your cluster.
- There is a communication failure between nodes and a warning appears that the cluster was unable to remove clustering components from the evicted node.
- You log onto the node in question and from a command prompt run "cluster node /forcecleanup"
The command responds with the output show in the screen shot below
Your server is now in limbo. You cannot un-install the cluster service and you cannot re-join the cluster, the cluster network driver and cluster disk driver are still online. Most people would re-install the server from scratch at this point. There is however a workaround that will save you time.
1. Open up regedit on the system in question & Navigate to HKEY Local Machine\Software\Microsoft\Windows NT\Currentversion\Cluster Server
2. Right click ClusterInstallationState and choose Modify
3. Change the value to 3
4. Click OK
5. Exit Regedit and reboot your server.
6. Log back into windows and go to a command prompt.
7. Run "Cluster node /forcecleanup" you should see the following output
That's it !! No rebuild required. You can now operate the node as a stand alone box or join another cluster.
The print spooler is a temperamental beast at the best of times. Print servers end up with a whole myriad of drivers, print monitors and print processors. The more queues and printers there are the greater the potential for problems. Clustering your print server makes sense but it does add another layer of complexity for you to manage. I recently tackled a problematic print cluster and thought Id blog about it. In this post I have pulled together information on how to “clean up” a clustered print spooler. I’ve drawn information from a few sources for this post. Big thanks to Paul Cook (Premier Field Engineer in the UK) for his advice … the man knows his print clusters :)
Before we begin, have a read of the following posts:
Right, so now you know how it all ties together. Let’s tackle a few problems that I encountered:
- Unsupported Print Monitors were installed
- Print Queues were using third party Print Processors
- Third party printer drivers
Unsupported Print Monitors are a common explanation for the spooler biting back.
WARNING
Use the Printing tool to take a backup of your current configuration BEFORE continuing. I would also advise that you take a system state backup to ensure that the cluster configuration is safe and sound. Let me re-iterate again, TAKE A BACKUP. Oh, and don’t forget to test everything before tackling your production systems!
Unsupported Print Monitors
When a printer is installed into a cluster using a driver that ships with Windows Server 2003, the cluster service only uses the standard TCP/IP or LPR monitors. No third-party monitors are supported on server clusters.
The following monitors are considered supported:
- BJ Language Monitor
- Local Port
- LPR Port
- Microsoft Document Imaging Writer Monitor
- Microsoft Shared Fax Monitor
- PJL Language Monitor
- Standard TCP/IP Port
- USB Monitor
- Windows NT Fax Monitor
Make sure that each queue is using the Standard TCP/IP port monitor. You can see the monitors installed on the cluster by viewing:
HKLM\Clusters\Resources\<resource id>\Parameters\Monitors
You should remove any unsupported print monitors from the above registry key once all queues are configured to use supported monitors.
Print Queues using third party Print Processors
The official line is that third party print processors ARE supported but NOT recommended (Microsoft recommend using the WinPrint processor). Print processors are user-mode dynamic-link libraries that are responsible for converting the spooled data of a print job to a format that can be sent to a print monitor. Print processors are also responsible for handling program requests to pause, to resume, and to cancel print jobs.
You wont know what processor a particular driver will use unless you edit the INF before installing. Realistically editing the INF is not an enticing option. I prefer changing the queue to WinPrint after you have set it up. So the the first challenge is to identify what Print Queues are not using the WinPrint processor. You could manually go through each subkey in
HKLM\Cluster\Resources\<resource id>\Parameters\Printers
Or, you could script your way out of the problem like this:
| Const HKEY_LOCAL_MACHINE = &H80000002 strLogfile = "C:\results.txt"
strComputer = "target server"
intCounter = 0 Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.CreateTextFile(strLogFile) Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "Cluster\Resources\<resouce id>\Parameters\Printers\" objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys For Each strSubkey in arrSubKeys
objReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", strPrintProcessor
objFile.WriteLine "Print: " & strSubkey & vbTab & "Print Processor: " & strPrintProcessor
intCounter= intCounter + 1
Next WScript.Echo "Finished processing " & intCounter & " printer queues"
objFile.WriteLine "Eunumerated " & intCounter & " printer queues" WScript.Quit |
This script creates a log file called results.txt listing the print processors for each print queue. Now you know what queues are not using WinPrint, how do you go about changing them? You have three options:
- Change it manually by going into the advance properties the queue, click Print Procesor and select WinPrint.
- Change it manually in the registry HKLM\Cluster\Resources\<resource id>\Parameters\Printers\<queue>\Print Processor
- Write a script to change all print processors to WinPrint.
| Const HKEY_LOCAL_MACHINE = &H80000002 strLogfile = "C:\results.txt"
strComputer = "target server"
intCounter = 0 Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.CreateTextFile(strLogFile) Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "Cluster\Resources\<resource id>\Parameters\Printers\" objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys For Each strSubkey in arrSubKeys
objReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", strPrintProcessor
If LCase(strPrintProcessor) <> "winprint" Then
objReg.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", "WinPrint"
objFile.WriteLine "Printer: " & strSubkey & vbTab & "Print Processor was: " & strPrintProcessor & " but has now been changed to WINPRINT"
intCounter= intCounter + 1
End if
Next WScript.Echo "Finished. Modified " & intCounter & " printer processors"
objFile.WriteLine "Modified" & intCounter & " printer processors" WScript.Quit |
Once you have changed all queues to WinPrint you could now remove the third party print processors from the cluster. However, think about the consequences before decide to delete them.
If a print queue is configured to use a print processor that no longer exists it will not appear when the print spooler is restarted. To get the queue back you have to edit the registry to change the print processor to WinPrint and restart the spooler.
Should you still wish to delete the print processors you will find them, depending on the environment in:
HKLM\Cluster\Resources\<resource id>\Parameters\Environments\Windows NT x86\Print Processors
Regardless of whether you delete the third party print processors every time you create a new queue or install a new driver, make sure you change the print processor to WinPrint.
In some instances using the WinPrint Processor can reduce functionality on a printer e.g. twisty text or watermarks and the likes. So, there may be instances where you have to use third party print processors. You could consider creating a new Print Spooler resource on the cluster for third party processors and leave all of the WinPrint queues on another spooler. Each spooler resource on a Windows 2003 cluster can have its own set of drivers, processors and monitors located in HKLM\Cluster\Resources\<resource id>\Parameters
Third party printer drivers
Third party drivers can impact the stability of your print cluster. As a general rule, see if you can use the drivers that ship with Windows Server 2003 before considering the installation of third party ones. Another thing that really kills print servers is running the setup program that comes with printer drivers. Not only is this not the supported method for adding a driver to a print cluster it also installs a whole lot of unwanted “stuff” (like system tray icons). Check out the Cluster Server Resource Centre for more details. Check out How to set up a clustered print server for details on how to setup the spooler and create print queues.
Conclusion
If you tackle the Print Monitors, Print Processors and Drivers you have gone a long way to ensuring that your print server is stable. However, there is one thing that very quickly undoes all of your hard work and that’s Terminal Services Printer Redirection. Imagine you’ve cleaned up your drivers, removed unsupported port monitors and set everything to use the WinPrint processor… all of a sudden different drivers start appearing on your cluster! I recommend disabling client printer redirection on ALL print servers, not just the clusters (in fact, I have in the past disabled it completely on all servers to stop printer drivers being installed). You can find the option to disable client printer redirection under:
Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection
Enable the Do not allow client printer redirection setting.
One last word
Windows Server 2008 Fail-over clusters are well worth looking into. There have been improvements across the board. Print Clusters are now easier to install, configure and manage. Click on the image below to learn more about Windows Server 2008.
I was recently asked (two hours ago) how to tell if a server was running Terminal Services in Application Mode. The customer wanted to run a different script if users were logged into a Terminal Server.
They had looked through the registry and came across the TSEnabled value in :
HKLM\Software\System\CurrentControlSet\Control\Terminal Server
While this key does indicate whether or not TS is enabled, it does not tell you if the server is in Application Mode. To compound the issue this key is also set to 1 by default on Windows XP. So, surely there was a more appropriate way to check? Indeed there is … the Win32_TerminalServiceSetting WMI class will allow you to check. See the code below:
Dim strComputer, objWMIService, colClass, objClass, strTSMode
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colClass = objWMIService.ExecQuery("Select * from Win32_TerminalServiceSetting")
For Each objClass in colClass
strTSMode = objClass.TerminalServerMode
If strTSMode = 1 Then
Wscript.Echo "Terminal Server is in Application Server mode."
Else
Wscript.Echo "Terminal Server is in Remote Administration mode."
End If
Next
Note: This will not work under Windows 2000 as the WMI class does not exist. I have not checked it in Windows 2008.
In my post yesterday I spoke about virtualisation candidates (amongst other things) and how we now know what loads and systems are viable. Have a look at the Microsoft Assessment and Planning (MAP) tool. Its the tool for identifying candidates. There is also a nice video demo from Baldwin Ng, showing the tool in action. The tool will remotely gather information regarding your enterprise without installing agents. The MAP tool then generates a candidacy report(s) that can be used to justify the investment including the hardware requirements for your virtualisation environment.
Note: The RTM version of MAP v3.0 only includes Virtual Server 2005. You will need MAP v3.1 Beta for Hyper-V. Check out this posting for details on joining the beta. It is still worth running the MAP v3.0 against your environments as virtualisation candidates should be the same regardless.
.png)
