The 497 Day Uptime Bug

Issue

1. All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup. Therefore, TCP/IP ports may be exhausted, and new TCP/IP sessions may not be created. All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup. Therefore, TCP/IP ports may be exhausted, and new TCP/IP sessions may not be created.
2. TCP/IP chimney offloading fails after 248.5 days. Therefore, systems will stop responding after 248.5 days if offloading connections are being used.

Resolution

• Schedule more frequent server reboots
• Apply a hotfix

Background

The reason that 497  is a problem number is because of the use of a 32 bit counter to record uptime.   If you record a tick for every 10 msec of uptime, then a 32-bit counter will overflow after approximately 497.1 days.  This is because a 32 bit counter equates to 2^32, which can count 4,294,967,296 ticks.  Because a tick is counted every 10 msec, we create 8,640,000 ticks per day (100*60*60*24).  So after 497.102696 days, the counter will overflow.

Some systems have a problem at 248.551348 days (half of that) if they use a signed 32 bit integer to store the value (one less bit to work with).

Note that this bug does not only affect Microsoft products. Other vendors to be affected by this bug include: Avaya, Brocade, Cisco, EMC, QLogic and VAX/VMS.

Links

• 497 days of uptime kills Windows
• 497 - The number of the IT beast
• MSKB 2553549 - ports that are in a TIME_WAIT status are not closed after 497 days

Best Practices for Virtualizing Domain Controllers

Virtual DC Best Practices

1. DCs require VM High Availability
2. Never pause, clone or snapshot a DC
3. Not all backups are created equal
4. Avoid clock drift
5. Don't overprovision resources
6. Ensure backups actually work
7. Implement anti-affinity rules
8. Separate client and administrative traffic
9. Prioritise quick object restores
10. Monitor storage performance
11. Remain a bit physical
12. Have a plan for disaster recovery

Reference documents

• Things to consider when you host Active Directory in virtual hosting environments
• Running Domain Controllers in Hyper-V
• Virtualizing Active Directory Domain Controllers: General Best Practices
• VMware Whitepaper - Virtualizing a Windows Active Directoy Domain Infrastructure
• Virtualizing Active Directory Domain Services On VMware vSphere

Different digital certificate formats

Certificates can be exported in a number of different formats. This blog aims to clear up any confusion around what these formats are.

When exporting certificates in Windows the following options are available.

1. Export the private key:

• .PFX format - Personal Information Exchange - PKCS #12

2. Do not export the private key:

• .CER - DER encoded binary X.509 - use this for non-Windows devices that require the cert.
• .CER - Base-64 encoded X.509 - use this for Windows devices that require the cert.
• .P7B - Cryptographic Message Syntax Standard - PKCS #7 Certificates - use this when you want to export the issuing and root CA certs bundled with the server cert.

How to migrate a XenApp database

Migrating the Database to a Different Version of the SQL Server

Migrating from one database version to the other might be necessary to move the data store to a more powerful server. The best method for migrating between versions of the database is to back up and restore the database using the utilities provided by the database software vendor.

To point a XenApp Server farm to a new database, complete the following steps:
Note: For the best performance, complete this procedure on the data collectors after all other servers are reconfigured.

• Back up the existing farm database and restore the database to the new server.
• Create a new DSN file that points to the restored database.
• Run the dsmaint config command on the server with the new DSN file.
• Stop and restart the IMA Service.

Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to initiate Dr. Watson, if SNMP is enabled. This error is benign.

• Ensure that the server is pointing to the new data store by verifying the following registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceName

• If the IMA Service started successfully, copy the new DSN file to all servers in the farm.
• Run the dsmaint config command to change the IMA Service configuration on all remaining servers in the farm.
• Stop and restart the IMA Service on all servers in the farm.

Tip: You can execute Steps 6 through 8 on all the servers from a simple batch file placed in a central location.

Applicable products

• XenApp 6.5 for Windows Server 2008 R2
• XenApp 6.0 for Windows Server 2008 R2
• XenApp 5.0 for Windows Server 2008

Further reading

• Data Store Migration Strategies (CTX123111)
• Advanced Concepts - XenApp Farm Maintenance (CTX677542)
• Data Store Migration Between Different Database Products (CTX121888)
• Supported Databases for Citrix Products (CTX114501)
• Citrix Presentation Server 4.5 Administrator's Guide (CTX112223)
• XenApp 6.5 for Windows Server 2008 R2 - Data Store Database Reference
• XenApp Server Utilities Reference

Citrix Receiver customizations

External links

• Configure and install Receiver for Windows using command-line parameters
• How to Customize App Shortcuts with Receiver for Windows
• How to Automatically Move Applications to Start Menu Using Receiver for Windows 4.x
• How to improve the user experience (ux)

Citrix Receiver apps open in the background - fixed

Issue

Citrix Receiver 4.x is installed on 64-bit Windows 8.x. Whenever an application is launched from Receiver by clicking on it, it opens in the background (behind the Receiver window). This may cause users to think that nothing is happening and prompt them to click the icon again.

Resolution

The following registry keys need to be applied to the client-side computer, But first, log out of Receiver, close and exit the application by right-clicking on the icon in the system tray / notification area and selecting Exit.

This can also be accomplished by copying the below text, pasting into notepad and saving as a REG file (e.g. "CitrixReceiverRegFix.reg") or by applying through Group Policy.

Note that the below keys are for 64-bit Windows clients. For 32-bit Windows clients, simply remove the "Wow6432Node" key from the entries below:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client]
"ForegroundProgressBar"=dword:00000001
"NotificationDelay"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\WFClient]
"TWISeamlessFlag"="1"

[HKEY_CURRENT_USER\Control Panel\Desktop]
"ForegroundLockTimeout"=dword:00000000

[HKEY_USERS\.DEFAULT\Control Panel\Desktop]
"ForegroundLockTimeout"=dword:00000000

Cloning Citrix XenApp servers

Links

• Server Cloning with Presentation Server 4.x and XenApp
• XenAppPrep Integration Utility for XenApp and Provisioning Services
• How Sysprep Works
• Cloning a XenApp Server with XenAppPrep
• Using XenApp Prep to Clone a Windows 2008 XenApp 5 Server
•