Poor Terminal Server Performance and Event Log 11728

I have had several Terminal Servers that have displayed poor performance including CPU spikes, application faults and slow printing. All have shown the MSIEXEC event ID 11728 in the Event Log. This is related to a HP Printer Driver that causes a fault if the user is a non admin, which will be all your Terminal Server Users!

HP do have an official line on this below.

HP UPD/Discrete LaserJet Driver - Microsoft Windows Event Viewer (Application) Message "HP CIO Components Installer" - hpzbdi32.msi / hpzbdi64.msi / hpzbdi.dll
Issue
Several reports of HP Bidirectional Channel components (hpzbdi32.msi /hpzbdi.dll , or hpzbdi64.msi /hpzbdi.dll ) could be the potential cause of various performance-related issues within standalone print servers, Microsoft Windows Cluster Server, Citrix, and/or Terminal Server environments, resulting in delays during driver installation, intermittent print spooler crashes, performance issues, CPU spikes, and so forth. CIO MSI does not get installed if a user with non-admin rights attempts to install the driver. The driver will attempt to install the MSI multiple times (five times, with an interval of two minutes between each try) without checking the access permission. This multiple execution causes a delay with the installation, and will launch multiple instances of the MSI installer, which can contribute to the cause of poor performance on the server.
The Microsoft Windows Event log (Application) will usually indicate a reference to: 32 Bit HP CIO Components Installer or a 64 Bit HP CIO Components Installer Product Version: X.X.X. Product Language: XXXX .
This issue may manifest itself with the discrete PCL 6, PCL 5, and Postscript drivers, which are bundled with hpzbdiXX.msi /.dll components. As hpzbdi is considered a legacy bi-directional component, there will not be any further updates or developments to this component. The workarounds that follow have been reported to resolve the majority of issues concerning hpzbdi.msi /.dll reports.
Product/Driver Packages Affected:
The following products have hpzbdi components installed as part of their driver package, and would qualify for the following workarounds:
• HP LaserJet 4250/4350 Printer Series
• HP LaserJet 9040/9050 Printer Series
• HP LaserJet 5200 Printer Series
• HP LaserJet P3005 Printer Series
Solution
The latest versions of hpzbdi.dll , which are not publically available at www.hp.com, and can only be procured by contacting HP Support, are as follows:
• 32-Bit: hpzbdi.dll (1.1.2.51)
• 64-Bit: hpzbdi.dll (1.2.2.51)
When the driver components are installed, the hpzbdi components are installed to the following paths by default:
• 32-Bit: C:\WINDOWS\system32\spool\drivers\w32x86\3
• 64-Bit: C:\WINDOWS\system32\spool\drivers\x64\3
NOTE: The hpzbdi files may also reside in additional folders named hewlett_packardhp_xxxxxx within the w32x86/x64 directories. It is not necessary to make changes to the hpzbdi files located in these directories, per the workaround instructions that follow.
Recommended Solution:
It is recommended to perform a clean installation/upgrade to the HP Universal Print Driver version 4.7.2, as it resolves the issue reported in this document. It should be noted that the HP Universal Print Driver PCL 6, PCL 5, and Postscript version 4.7.2 are not available at www.hp.com. Although this is a fully Microsoft certified driver, which has been through the Microsoft Windows Hardware Quality Labs (WHQL) certification, it is only available from HP Support.
NOTE: Click here to review additional information related to UPD installation/migration at www.hp.com/go/UPD.
It is possible a UPD upgrade to version 4.7.2 is not a viable option, due to logistics beyond the immediate control of the customer. Should this be the case, alternative steps can be taken to address this issue.
Workaround #1:
Zero-byte the MSI Installer Package, which will eliminate the symptomatic behaviors of the issue noted in this document. Complete the following steps:
1. Open Notepad and save the file as hpzbdi32.msi or hpzbdi64.msi . This zero-byte file will not contain any data.
2. Navigate to the %WINDOWS%\system32\spool\drivers\w32x86 (32-bit operating system) or %WINDOWS%\system32\spool\drivers\x64\3 (64-bit operating system) directory, and locate the hpzbdi32.msi or hpzbdi64.msi file. Rename the file to hpzbdi32.old or hpzbdi64.old .
3. Copy and paste the newly created zero-byte file named hpzbdi32.msi or hpzbdi64.msi into the %WINDOWS%\system32\spool\drivers\w32x86 or x64\3 directory.
4. Verify functionality.
NOTE: Depending on configuration, it may be necessary to stop the spooler, perform the steps noted, and then restart the spooler.
Workaround #2:
Complete the following steps:
1. Working with HP Support, obtain the hpzbdi hotfix , which contains either the 32-bit: hpzbdi.dll version 1.1.2.51 and/or 64-bit: hpzbdi.dll version 1.2.2.51.
2. Navigate to the %windows%\system32\spool\drivers\w32x86\3 directory for 32-bit operating systems, and rename hpzbdi.dll to hpzbdi.old .
3. Copy and paste the hpzbdi.dll version 1.1.2.51 hotfix to this working directory.
NOTE: For 64-bit systems, navigate to %windows%\system32\spool\drivers\x64\3 . For step 3 copy and paste the hpzbdi.dll version 1.2.2.51 hotfix to this working directory.
4. Verify functionality.
NOTE: Depending on configuration, it may be necessary to stop the spooler, perform the steps noted, and then restart the spooler.
How to Obtain Support for this Issue:
Customers: If you require the hpzbdi hotfix , as outlined in this document, please contact 1-800-HPINVENT and report the issue to the HP Support agent. Request the hpzbdi hotfix and refer to this document.
HP Support: If an HP customer contacts you to report this issue, and to request the hpzbdi hotfix , please contact your Resource team for immediate consultative action.

Renew Exchange 2007 SSL Certificate

Once your Exchange 2007 SSL Certificate is due for renewal you will need to perform the renewal process, this is slightly complex and requires the right steps to be taken.

1. First you need to request the new certificate from Exchange to generate the CSR that is needed for your SSL Provider. I use www.digicert.com as they have a nice wizard to generate the Exchange 2007 Shell command for you. In my instance I used this Shell command to generate my certificate

New-ExchangeCertificate -GenerateRequest -Path c:\mydomain.com.csr -KeySize 2048 -SubjectName "c=GB, s=West Midlands, l=Birmingham, o=My Company Limited, cn=mydomain.com" -DomainName server, server.mydomain.local, autodiscover.mydomain.com -PrivateKeyExportable $True

This now creates the CSR file you can send to the SSL provider for processing.

2. Once you have received your new SSL certificate you need to replace the expired or close to expired SSL certificate on your Exchange Server. You next need to run the Exchange Shell command

Get-ExchangeCertificate | fl | out-file –filePath c:\certs.txt

This will output your existing certificates to a text file you can read, open the file and find the certificate with the "Not After" date that is the expiry date of your certificate. Make a note of the thumbprint information and copy this to the clipboard.

3. Next you will remove the existing certificate with the command below and the thumbprint information on the clipboard

Remove-ExchangeCertificate –thumbprint

Confirm you want to remove the certificate.

4. Now you can import your new Certificate from the CER file supplied by your SSL Provider

Import-ExchangeCertificate -path e:\certificates\owa.cer –FriendlyName “owa.mydomain.com”

This will output the Thumbprint for the next Certificate and you need to make a note of this long file information.

5. You now need to enable the certificate for use in Exchange 2007 with the command

Enable-ExchangeCertificate -Thumbprint B52842F7408772B7151FF74FDAE914EA7B59B53A -Services IIS

Replace the Thumbprint with the Thumbprint from your previous notes.

6. The Certificate is installed and enabled now, you can run the command

Get-ExchangeCertificate

This will show you the certificate and that it is enabled for Web Access with the "W" in the Services section.

Disable IE8 Customisation Page with Regedit

Sometimes on a Terminal Server you dont want that Splash Screen for IE8 showing as the end users cannot find which options to choose and start calling the helpdesk, so you choose to disable it for them.

This is simple with Group Policy if you have a Windows 2008 or Windows 7 PC but what if you are all Windows XP and 2003? Then you need a custom ADM or a registry edit to achieve this.

HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Internet Explorer \ Main

Reg Dword - DisableFirstRunCustomize = 1

The branches above will not exist in the Registry so you need to create the last two manually first.

SBS 2008 Migration fails with "Source Server does not meet requirements"

We were performing a migration from SBS 2003 to SBS 2008 and when the answer file was being checked during the upgrade we saw this error displayed and the list showed that the source server did not meet the requirements for Active Directory Schema and Exchange Server Service Pack level.

We knew that the source server was correct and the BPA had passed all tests so I thought it must be a communication issue from the SBS 2008 Server to the source server, I opened Wireshark and could see traffic from the SBS 2008 Server to the source server so the next step was to see if the SBS 2008 Server could ping the source server by Netbios and FQDN as these are part of the answer file.

During SBS 2008 Server setup you can press SHIFT + F10 and have a command line load, this is invaluable for trouble shooting and a quick ping showed we could not ping the Netbios or FQDN of the source server. I edited the HOSTS file on the SBS Server and updated it to resolve the source server correctly and ran the answer file check again....

Bingo! The tests passed and the installation continued. Lesson learnt, always test your DNS and WINS before you start. In this case my engineer explained he had had to change the IP range on the source server from a class B address to a class C address and this then told me DNS had not updated correctly and this is why DHCP on the SBS Server 2008 did not resolve the names correctly.

Delete files older than a certain age

I had a need to delete some backup images files from a share after a period of time so that the disk did not run out of space. This was because the backup application Acronis & Backup Recovery 10.0 was not able to correctly clean up older image files in the backup rotation.

So to create a simple way to delete all image files older than two days I used the FORFILES.EXE utility from the Windows 2003 Resource Kit.

The syntax for this is quite simple and allows you to search a location or sub folder for a file type and then take an action depending on the files found. So for my case I used

forfiles /P E:\myPath /M *.TIB /D -2 /C "cmd /c del /q @path"

This command uses the path E:\myPath and then finds TIB file extensions, it tests if they are older than 2 days and if it matches it then runs a del /q to delete these files using the full path.

NtFrs Event ID 13566

I had a server that had the event ID below

The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\winnt\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

I have had this error in the past and I have followed the registry edit to request FRS rescans for Active Directory changes, in this instance when I made the change the server had been in this state for so long it removed all files from the SYSVOL Share under SCRIPTS and POLICIES and rendered the server no longer a Domain Controller.

This was a pretty difficult situation as this was a SBS 2003 Server and this meant I had no other DCs to connect to bring AD back online.

I had to use the BurFlags registry changes to rebuild FRS again and start with an empty, to do this I had to perform an Authoritative Restore from this Microsoft KB article.

http://support.microsoft.com/kb/290762

Once this was complete I had the SYSVOL share back again after about five minutes but I had to manually recreate the SCRIPTS folder for this to be shared as NETLOGON. The Policies folder was missing from SYSVOL so I had no Group Policies and numerous UserEnv errors in the event log.

The next step was to rebuild the Default Domain Controller and Default Domain Policy, this can be done using the DCGPOFIX tool on the SBS Server, I ran this and accepted the Disaster Recovery options and this rebuilt the two Group Policies correctly.

Now I had to recreate all the SBS Custom Policies that no longer existed, for this I was able to export the policies from an existing SBS 2003 Server and then use the Import Settings option to rebuild the policies. As the polices do not reference any Security SIDS directly these policies could be imported.

This now returned the server to a state where the Event Logs were clear of errors, Exchange and SQL Server were working and I had only to recreate the logon script files in the NETLOGON share.

Change IP address from the command line

Here is a very simple way to change the IP address from the command line, very handy when you cannot get into the GUI and only cmd will load from task manager.

http://support.microsoft.com/?kbid=257748