Just a quick one, I had to do this the other day with our certificate. I know that you can do this on the F5 through an SSH connection. But I decided to use the version I had installed on my Windows Desktop.
After a few moments of bashing my head against the proverbial brick wall I found that this was the way to do it.
For those interested I was doing this so that I could import our wild card certificate into my Citrix Gateway as the versions that I could download from verisign were not compatible and gave an error on import. In fact I will try to get a post up about that.
If you follow these steps you should end up with a cert that will have the Private key and will work if Citrix or VMware view for that matter.
On the F5 export the Certificate file and key file. Copy them somewhere you can find them. I actually put mine in the OpenSSL folder. That way I didn’t have to worry about typing paths! Yes I am that lazy!!
Open a command prompt and start OpenSSL
Type the following pkcs12 -export -in .crt -inkey .key -out .p12
You will see a message saying “loading ‘screen’ into random state – done
It will then prompt for a password to allow the Private key to be exported. This is important for Applications like the Citrix Secure Gateway
You will then see a message saying ” Verifying – Enter export password:” So go ahead and confirm your password
And that is it. Pretty straight forward when you know how, and you will have a nice new certificate with private key that can be exported.
I have recently had to move all of my Xenapp 6.5 databases from an old SQL2005 server to a new SQL2008 server. For the most part it went well but I did encounter the following error, that is pretty simple to solve.
After moving the CL database I went and reconfigured the Configuration logging settings, using the wizard in the Appcentre. That all went well and it was happy talking to the new DB. I then went and made a simple change to an application, so that I could query the change log. What I found when I hit the get log button was the following error came up.
“The EXECUTE permission was denied on the object”
Ok, so its access denied. Seems pretty simple. I went back to my DBA and we checked that the Stored Procedures were there (Which they were) and we re-applied permissions to the Citrix service account. It seemed that no matter what we did the error persisted.
After a quick SQL trace we could actually see that when you hit “get log” it uses the logged on user account to query the DB. So adding the correct AD group to the CL DB on the new server fixes this issue. Simple stuff, but it may help someone else if need be.
I dont intend on reinventing the wheel here as there is already a great blog post detailing this process which you can find here My thanks to Terrance for his work on this blog. I just wanted to add a couple of findings based on my experience of the process.
I do agree with Terrance that the Citrix docs are not great and that is why you should follow his post, much as I did.
Lets start with a little bit of background on my setup. I have 9 Xenapp servers in my single farm, with one data collector. I had to try to do this move during the day as my DBA was not available out of hours for the usual maintenance window, and we could not wait or defer the move until he was. Catch 22 then! Typical….
So here was my plan.
Disable logons the day before the move to the data collector
The following day I will stop the IMA on that server
The IMA services and 8 other XA servers will all be left with logons enabled serving users
The DBA will back up and restored the DB to the new server
We will then take the original DB on the old server offline, cutting off the 8 live XA servers
At this point I would test that I could access a few applications – This would test that the local cache was working
I will then repoint the data collector to the new DB server using Terrances steps
After the IMA service restart I will test an application launch and change from the data collector server
I will then have a maintenance window in the evening to perform the process on the other 8 XA servers
First question to answer is. Did I follow this plan and the answer is yes. And for the most part it all went well, there are just a couple of gotcha’s that I didn’t fully think through, so I will list them out for your consideration. They all make perfect sense when you consider that they have no real-time access to the DB anymore.
I found that Citrix shadowing didn’t work whilst the live XA servers were running in cached mode. Support staff were unable to enumerate users.
Opening the App Centre on a cahced server would prompt a discovery to run, which would fail. You could only run App centre on the server that was migrated
You could not control the logons to the servers running in cached mode
My last point is just for clarity, you can move the DB without stopping all of the IMA services on your XA servers
As per usual I hope this helps someone else out there. None of this is rocket science but sometimes it just helps to read about someone elses experience!
Putting Chrome into Citrix as a published app was interesting. I found that just calling the exe would bring the browser up but I could not actually browse the web.. D’oh! I would get a grey screen with a 404 error. Opening IE proofed that I could browse fine in a Citrix session.
After a little playing I found that I needed to add the following switches after the exe. Doing so enabled me to get to web sites.
I then wanted to have Chrome launch a internal website.i found that you have to put the URL before the switches, otherwise you get the same 404 message.
For example. C:\program files\google chrome\chrome.exe http://mysite –allow-no-sandbox-job –disable-gpu
I have been working with XenApp a lot just lately and I find myself knee-deep in the Citrix e-docs a lot. However I think that they don’t cover some topics particularly well, especially when they don’t seem to want to acknowledge that other vendors exist.
So, here are my simple steps using VMware and Citrix. You don’t need to bother with provisioning server etc. I am aware that there are many ways of doing this but I consider myself to be a Citrix novice so keeping it simple is the way to go!!
Please note this was done on a 2008 R2 server running XA 6.5 FP1.
Ensure that you have configured a guest customisation script in your virtual centre. If you don’t you could use Sysprep, I would suggest using generalize and oobe.
Jump onto a XenApp server, so long as it’s not the first server in the farm, as you should not image that. Ensure that you have all of your apps installed and configured and ensure that no users are logged in.
Open the Citrix role manager. Select the XenApp role and click configure. If you cannot find it either someone has uninstalled it or go and find it under C:\Program Files (x86)\Citrix\XenApp\XenAppServerRoleManager\
Select to prepare the server for imaging
Now I wanted my server that I was imaging to remain in the farm, so I unchecked the top tick box. This means that my server will just rejoin the farm after the next reboot. This also means that I don’t want the database locations to be wiped. So I left the bottom check box clear. This also means that I didn’t have to create any policies to set the server information.
Finish the wizard and go to services. You will need to stop and disable the Citrix IMA service
Now, if you’re not using a VMware customisation script, now would be the time to use Sysprep. You will find Sysprep in C:\windows\system32\sysprep
Now shut the server down and use VMware to clone the server, your customisation script should rename the server and sysprep the machine. I am not going to detail these steps, but if you get stuck drop me a comment and I will give you a hand 🙂
You could now power up the machine that you imaged and set the IMA service to automatic and start it up.
Then you can power up your clone and do the same with the services, but only after you have checked over Windows.
That should be job done, clearly you could do multiple clones and you could do a clone to template but there may be some other caveats there, so I would do a little R&D before you do that.