Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.
There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:
That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.
Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.
A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.
Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.
I received complains from a customers who wasn’t able to add two new Citrix servers to his Citrix Access Gateway configuration. He could successfully add the first Citrix server, but he couldn’t add the second Citrix server, because the first was overwritten by the second. I looked at the problem and noticed that both Citrix server were using the same STA Identifier.
After asking some question about the installation of the Citrix server, I discovered that the second Citrix server was a clone of the fist Citrix server. That is why both servers have the same STA Identifier. The STA ID from a Citrix server can be changed by altering the file CtxSta.config. By default a Citrix server has two CtxSta.config files, located at the following destinations (default installation):
I had to change the STA ID in the C:\Inetpub\Scripts directory, because IIS was used to share port 80 on the server. The CtxSta.config file contains a UID, like the example below:
; Allowed Client IP addresses
; To change, substitute * with client IP addresses. Use ";" to seperate IP addresses/address ranges.
; To specify a range of IPs always use StartIP-EndIP.
; For example, AllowedClientIPList=192.168.1.1;10.8.1.12-10.8.1.18;188.8.131.52
; SSL only mode
; If set to on, only requests sent through HTTPS are accepted
I changed the UID on the second server and restarted IIS. I tried to add the Citrix server to the Citrix Access Gateway, which is now possible with the new unique STA ID. The last step is adding the second Citrix server to the Citrix WebInterface (server farm & STA ID).