Category Archives: Windows Server

“Why can’t I click OK?” – Resizing the Citrix Logon Window

Many clients that I work with (I’d say over 90%), have logon disclaimers that must be acknowledged prior gaining access to enterprise resources…seen below is simply an example I found online to serve as a frame of reference:


When publishing applications from Citrix XenApp, if the logon banner is applied via GPO at the domain level, users must acknowledge the disclaimer when accessing published applications….so they acknowledge once when logging into their domain computer, and then again when launching published applications.

Thus, some organizations disable the logon disclaimer on the by disabling policy inheritance on the XenApp Server OU and others leave the disclaimer in place so as to ensure any users making XenApp connections from non-domain computers will have to acknowledge the logon disclaimer.

The problem I have seen when using Server 2012R2 is that the logon disclaimer is “larger” than it was with Server 2008R2 and thus when the users launched applications from the 2012R2 server, the logon disclaimer page had a scroll bar.  If the scroll bar was not to the far left of the disclaimer page, the OK button “wouldn’t work”, which confused the users.

Citrix support told me the logon disclaimer window has a default size of 600 (W) and 520 (H) but that the size can be adjusted (in this case increased) so as to get rid of the scroll bar in order to maintain the focus of the disclaimer window.  To set the width and height of the logon disclaimer window, add the following registry keys:

  • HKLM\Software\Wow6432node\Citrix\CtxHook\AppInit_DLLS\Multiple Monitor Hook
    • Name: LogonUIWidth | Type: REG_DWORD | Value: 800 (Decimal)
    • Name: LogonUIHeight | Type: REG_DWORD | Value: 600 (Decimal)


After creating the keys shown above, the logon disclaimer window was larger, the scroll bar was gone, and the users could once again click OK without worrying about focus or scroll bars.  The change did not require a reboot of the XenApp server(s).



1 Comment

Filed under Citrix, Windows Server

Error 0x80092013 When Starting an Enterprise Subordinate CA

Working on a Windows 2008 two-tier Certificate Infrastructure implementation, the installation of the Root CA went without a hitch, but when trying to start the certificate server service on the Enterprise Subordinate CAs, I received the error (in summary): “0x80092013 certificate revocation server is offline”.

Whether its right or wrong, what I had attempted first when building the Root CA, is to specify a UNC path the the Root’s CRL in the Extensions tab of its properties. I had past success using UNC paths when working with Windows 2003 certificate servers and figured that Windows 2008 would work more or less the same, and I guess it does, but in this particular case it was less.

Opening PKIView on the Enterprise Subordinate CA after the service failure, I saw a screen similar to the one below, taken from this blog post:

I won’t bore you with all the details, but to resolve the issue, I used an HTTP path for the Root CRL extension pointing to an IIS virtual directory on the Enterprise Subordinate CAs. Once the CRL was copied to the Subordinate CAs, the certificate services started without a problem.

Another option would have been to disable/ignore the CRL check as found below:

I have not figured out why the file/UNC path to the CRL did not work. Perhaps there will be time to explore it further.


Filed under Certificates, Windows Server

How to Force a DC to Attempt Certificate Autoenrollment

After installing a new Microsoft Certificate Server, the Event Logs on the Server 2003 domain controllers displayed an Autoenrollment error, Event ID 13 (Access is Denied) while on the 2008 domain controllers, an Event ID 13 error with the Source CertificateServicesClient-Request….or something close.

The fix for the Autoenrollment problem was the following found on an MS Support Forum:

The event 13 from Autoenrollment message may be related to the new DCOM security enhancement of Windows Server 2003 SP1. Windows Server 2003 Certificate Services provides enrollment and administration services by using the DCOM protocol. Certificate Services provides several DCOM interfaces to make these services available. For correct access and usage of these services, Certificate Services assumes that its DCOM interfaces are set to allow remote activation and access permissions.

However, Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. Specifically, SP1 introduces more precise rights that give an administrator independent control over local and remote permissions for launching, activating, and accessing COM servers. Therefore, because of the enhanced default security settings for DCOM that are introduced by SP1, you may have to update these security settings to make sure of the continued availability of these services after you install SP1.


1. Please check to ensure that a new security group, CERTSVC_DCOM_ACCESS, has been created after applied the SP1.
2. Please add the “Domain Users”, “Domain Computers”, “Domain Controllers” groups to the new CERTSVC_DCOM_ACCESS security group.
3. Then, we can have Certificate Services update the DCOM security settings by running the following commands:

certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc.

Thinking I had my problem fixed, I wanted the DCs to attempt an autoenrollment once again, however, in my impatience, I didn’t want to wait for this to happen.

Performing the steps listed below (they worked for 2003 and 2008) forced a certificate autoenrollment on the DCs:

1.    Backup/Export the registry key:             

2.    Delete the AEDirectoryCache registry key

3.    From the Command line, execute GPUPDATE /FORCE

Shortly thereafter, I reviewed the Event Logs on the DCs and they stated certificate autoenrollment was successful at which point I opened the Certificate Authority MMC on the CA and saw that certificates had indeed been issued.


Filed under Certificates, Windows Server

An "Oh-No" moment with Exchange 2010, demoted DCs, and the EMC Cache File

This week I demoted an older domain controller, one which originally hosted the FSMO roles, though they had been moved off.  The demotion went just as expected, server was rebooted, everything appeared to be fine.
As a side note, Exchange 2010 had been installed and all Exchange services and mailboxes migrated a few weeks prior to this demotion…
Shortly after demoting this server, an Exchange Administrator tried to open the Exchange Management Console to create a new mailbox and “discovered” that they couldn’t see anything.  Mail was flowing, the Exchange services were started, OWA worked, etc, but the system could not be managed.  For example, when expanding the Server Configuration menu, if we clicked Mailbox, we were told there were not mailbox servers in the organization.  If we clicked Client Access, we were told there were no client access servers in the organization, etc, etc.
When opening the properties of a mailbox user, clicking on any tab displayed an error message stating that Exchange could not read from a domain controller.  This was not looking very good….
Reviewing the Application Event Log revealed many “MSExchange Configuration Cmdlet – Remote Management” errors with Event ID’s 4 and 5.  Event ID 4 displayed the following text on the General information tab:
(PID 10132, Thread 24) Task Get-UserPrincipalNamesSuffix writing error when processing record of index 0. Error: Microsoft.Exchange.Data.Directory.SuitabilityDirectoryException: An Active Directory error 0x51 occurred when trying to check the suitability of server ‘DEMOTED DOMAIN CONTROLLER‘. Error: ‘Active directory response: The LDAP server is unavailable.’ —> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.

Fortunately for us, the answer to our problem was found pretty quickly with the Microsoft KB article:
Basically it says, “It is correct that the DC, mentioned in the application log is not available. The server may have been demoted, nevertheless Exchange still tries to connect to the unavailable DC.  This obsolete Information is cached in an EMC file in the Windows profile with whom user has logged into the server.”
Sure enough, a cached EMC file was found within the Windows profile for the Exchange Administrators.
Once deleted, we were able to administer the Exchange 2010 system without the Domain Controller read errors. One more thing to keep in mind….when I originally deleted the EMC cache file for one administrator, I was unaware that he had a disconnected remote session with the EMC open.  The errors continued until we closed the EMC and deleted the cache file once again.  So if you deleted the EMC cache file and the error still continues, it may be because an RDP session was disconnected with the EMC open.

1 Comment

Filed under Microsoft, Windows Server

Upgrading SQL 2000 to 2005…..I know

Believe it or not, this night, I upgraded a SQL Server from 2000 to 2005.  During the upgrade, the following error was presented, luckily before any files were written:

Turns out, J-F Tourigny (thanks very much!) had the same problem when trying to upgrade from MSDE 2000 to SQL Express 2005.

“When trying to upgrade MSDE 2000 to SQL Express 2005, the installation would fail during the upgrade advisor with error -1.  In Application log, Event 5000 was generated for process “bpacmd.exe”.  A quick search on the Internet revealed that the process is looking for BPAClient.dll in the wrong directory. Creating folder %ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\BPA\BPAClient and moving the DLL into this folder solved the issue”

The same solution worked for me when upgrading SQL from 2000 to 2005.

Leave a comment

Filed under Windows Server