Deloy Citrix Merchandising Server with Receiver 2.0 using anonymous access

Citrix Merchandising server 2.0 adds in the ability to deploy the receiver with tokens. This allows the receiver to be utilized with anonymous access and elimates the need for users to login for receiver updates (note this doesn't change the need to login for online plugin which will be presented as a receiver login prompt, don't confuse the 2 different authentication prompts)

For this I used both Merchandising server 2.0 and 2.1 along with Receiver 2.0 and 2.1.

Configure the Merchandising Server

1. Download and import the merchanding server (8GB HD space req)
2. Configure with IP, subnet, etc and install the latest XenServer tools. Use receiver.yourfqdn as the hostname
3. open https://ipaddress/appliance
4. login as root with the default password (found in the citrix edocs, note this is different than the unix password you configures from the console)
5. Configure Active Directory
1. Source Name = your call
2. Server Address = IP address to DC
3. Server port = 389 or 3268
4. Bind DN = user account to sync ldap (ie ldap@here.contoso.com)
5. Bind Password = the password to the ldap account
6. Base DN = your base dn (ie DC=here,DC=contoso,DC=com)
7. Save (if it errors you did it wrong)
6. Permissions
1. In the search users box type your domain user first or last name (username will result in nothing)
2. Select the radial button and click Edit
3. Change to Admin
4. Repeat for all other admins
5. Logoff
7. Enter a dns record for "receiver" pointing to the merch server IP address
8. point your browser to https://receiver/appliance
9. Logon as your newly configure admin account. Note that you'll need to use domain\username for now
10. Go to configurations - options
11. Enter your support desk email, website, phone as desired. Ensure you select Token Expiration of Never (unknown to me at this time if you set it to expire if the end clients will update automatically, or if it will just break it).
12. Enter the default domain name desired (note that this will fix the need for using the domain\username format)
13. Save
14. Go to configurations Authentication
15. Click Generate Token (needed for the anonymous access)
16. Click Save
17. Now we need to generate an ssl cert. Since most intermediaries now require all ssl certs be generated with 2048 or higher you won't be able to use the CMS built in cert request as it only generates at 1024. I used IIS7 for this.
1. Open IIS manager
2. On the server find Server Certificates
3. Click Create Certificate Request
4. Common name = receiver.ncgi.com
5. Fill out rest of the request and generate the csr
6. Copy the contents of the CSR and generate a cert (I used Godaddy)
7. download the completed cert
8. In IIS7 select the cert and click "Complete Certificate Request"
9. Once finished select the cert and click export
10. enter a location and password
11. Download and install openssl http://www.openssl.org/related/binaries.html
12. Convert the new cert from pfx format to pem using openssl
13. open command prompt and navigate to where you installed openssl (default is C:\openssl\bin)
14. openssl pkcs12 -in c:\certs\yourcert.pfx -out c:\certs\receiver.pem –nodes
15. Enter the password you gave it when you exported it.
18. Now that we have a cert in the proper format we can import it to the receiver. Go to configuration - ssl certifcate management
19. Change the drop down to "import certificate from a certificate authority"
20. For "Public Certificate File" browse to the newly created pem file
21. For "Private Key File" browse to the newly created pem file
22. Enter the password
23. Submit
24. The CMS will reboot at this point. When it comes back up you'll notice that you don't get a cert warning anymore (provided everything was done right).
25. Dedicate an external IP address and map the external address to your internal address at your firewall. You'll need port 443 open obviously.
26. Get the A-records mapped externally for receiver.fqdn to point to your external address if you haven't already
27. under plug-ins click Get new
28. select a plug-in that you want and click Download to server
29. under Deliveries click Create/Edit
30. Create
31. Delivery Name = Default
32. Check mark default delivery
33. enter how often to check for updates
34. Add a plug-in to push as the default package
35. Set the schedule for Deliver Now
36. Click Schedule

Package the receiver
Citrix has a tool available for packaging the receiver. It works very well. Unfortunately I don't like it because it forces you package it alongside the Access Gateway client, which I don't necessarily want to push to all my workstations that will be using receiver. If you want to push that client as well then use this to package your receiver with the token.
Otherwise:
Here's an excellent tip on packaging the receiver. http://www.xenappblog.com/2010/receiver-asking-for-logon-information-after-msi-install/
Download the receiver msi from citrix.com. Then make your installation look like the below. Note that the token comes from the "Authentication" tab in the receiver. It's the token we generated way back on step 15.
start /wait msiexec /i "Receiver.msi" /qn ALLUSERS=1 REBOOT="ReallySuppress" SERVER_LOCATION=https://receiver.fqdn.com/appliance/services/applianceService VERBOSE=true AUTOUPDATE=true TOKEN=yourtoken
Alternatively you could use Orca to modify the msi.
New! Citrix has added a new page in their edocs regarding how to push the Citrix receiver and the switches available. You'll find it under Receiver for Windows - Installing Receiver for Windows.

Citrix Online Plugin SSOn with Windows 7 x64

I was having issues getting SSOn working with any version of the Online plugin on Windows 7 x64. Mainly I was working on getting it running with the Citrix Receiver 2.0 deploying Full online plugin 12.1.

Checked that ssonsvr.exe was indeed running.

Found that the GPO template provided by Citrix contains what appears to be invalid entries for the SSOn keys. (note that SSOn for winXP working using these settings)
http://forums.citrix.com/thread.jspa?threadID=262201&start=0&tstart=0

Finally, discovered that it *was* the credentials that SSOn was attempting to use. I found that using the FQDN for the domain field would result in a failure, but using the "pre-Windows 2000" domain name would work.

Bingo, the PNA services site was set to allow only the "pre-windows 2000" version of the domain name. On the services site I added a second allowed domain name as the fqdn and everything took off running. Apparently XP was passing through the domain name that I had allowed, whereas Windows 7 was using the FQDN (which would make sense).

Remove Sleep and Hibernate from Start Menu in Windows 7 via GPO

Looking around on the internet I found a LOT of incorrect and incomplete information on this.


To remove the sleep and hibernation options from the Windows 7 start menu via GPO do the following (this doesn't disable sleep entirely, just removes it from start menu, to disable sleep via GPO you can do a power plan with it set to 0 and then select the power plan):


Sleep:

Computer Configuration\Policies\Administrative Templates\System\Power Management\Sleep Settings
Allow Standby States (S1-S3) When Sleeping (Plugged In)
Set to disabled







Hibernate

Note that I tried changing the HibernationEnabled key with no success. Running processmonitor I found that this key and many others are updated, contrary to many of the posts I found on the internet. In addition I found that many of the proposed adm templates for this actually caused GPO processing failure (so beware).


Computer Configuration\Preferences\Windows Settings\Registry
Action - Update
Hive - HKEY_LOCAL_MACHINE
Key Path - SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Value Name - DisableHibernate
Value Type - REG_SZ
Value Data - %systemroot%\system32\powercfg.exe -h off
Common Tab - Apply once and do not reapply (optional)