VMWare View on IAG & UAG - Borrowing Advice!

Good to see that my advice from this blog post is of use:
http://blog.andytang.com/2010/05/vmware-view-on-microsoft-iag.html

Spot the differences:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025861

http://www.nappliance.com/blog/uag-publishing-vmware-view-using-forefront-unified-access-gateway

I don't have issue with my advice being used, but at least show credit from where it was from!

ActiveSync and email on iPhones (and other ActiveSync devices)

Recently I’ve been asked a lot about ActiveSync for iPhones, but I try to highlight the security implications for this.

I have spoken with a number of people who have ActiveSync running on their Exchange Servers, where they can access the server directly from the internet. I’m not a fan of having servers on the LAN available from the internet, but the pressure to deploy the access this is often overlooked. Especially as the Microsoft IAG and UAG solutions will allow you to reverse proxy the ActiveSync connection, eliminating the need for a direct connection to the Exchange server.

Ensure the handset you have has a level of encryption on it, as the company can be subject to hefty fines from the ICO, if personal data is not encrypted. Apple iPhones have AES 256-bit hardware encryption to protect the data at rest. The Nokia E-series that I have investigate have encryption on both device and storage memory.

Although as this is protecting data at rest, ensure there is at least a password on the device, or there is no point having the encryption. Enforcing password on the device, and comprehensive password policies can be created on from the Exchange server.

 

What is the handset is stolen? There is the ability to remote wipe the mobile device, as well as enforce a wipe if there are too many failed attempts to logon to the device.

 

The only concern is a number of requests for this access on personal iPhones, which is a worry from a data leakage perspective. Although a number of places have said they will ensure password policies and reserve the right to remote wipe the device when it is required, then make their employees agreeing to this. Personally, I am not a fan of this and would rather be working with corporate devices, where as a business you have more “rights” to your hardware.

 

From a technical perspective, you will need to do the following:

• Ensure ActiveSync is configured and running on the Exchange server, with the relevant password, encryption and wipe policies. Assign the access to the users who should be able to access it, taking care to remove access from everyone else (so they are unable to connect up unauthorised or personal mobile devices).
• Configure an ActiveSync portal on IAG, or create a portal for ActiveSync on UAG.
• Ensure all the Exchange server settings are entered correctly.
• Apply a real SSL certificate to the portal, as some mobile devices will not allow you to except a self signed SSL certificate.
• Publish the portal.
• Test the ActiveSync by defining the server name, domain/username and password here: https://testexchangeconnectivity.com/
• Expect it to fail on the OPTIONS section, but everything else should pass.
• Configure your device to point to the newly created portal.
• Allow device to synchronise and enjoy emails on your mobile device!

 

VMWare View on Microsoft IAG

VMWare View has been a bit of a pain to a number of people, but here what I have done in the past to get it to work.  (Thanks to Andrew Button for helping to remind me of some of these bits!!)

Let me be clear, I am not a VMWare expert in any fashion, and I have little knowledge of VMWare View!

1. Ensure VMWare View works internally first
2. Ensure a VMWare Security Server has been deployed (this tip was thanks to my  friend, Google)
3. On IAG, publish a "Enchanced Generic Client App (hosts optional)"
4. Give the application a name and the right access policy
5. Give the server name that is hosting the VMWare View server, with the correct port (probably 443, if you are using HTTPS), iexplore as the executable, and the argument is the full URL for the service
6. Finish the wizard
7. Go into the properies and ensure that the Socket Forwarding Mode is set to VPN
8. Publish and test

I have been struggling with making this SSO, but no joy.  If this changes, I will update this post!

ASP Error when configuring File Access within IAG

I was on site when I encountered an odd issue.  When configuring the File Access component within IAG, we got teh following ASP error:

Request object error 'ASP 0104:80004005'

Operation not allowed /whalefilesharingadmin/computers.asp, line 47

Thanks for Senthil from Celestix who found the answer to this.

The error was being caused due to the size limit in IIS for the maximum number of bytes allowed in the entity body of an ASP request.

The answer is to locate this file:

C:\Windows\System32\Inetsrv\metabase.xml

and modify the following value:

AspMaxRequestEntityAllowed to 1073741824

This changes the excepted size limit to 1GB.

Testing IAG SP2 Update 3 - Part 3

Having been distracted from IAG with the impending launch of UAG on the Celestix platform, and Websense launching their Triton platform, I finally found time today to do some more testing.

Uri from Eurodata dropped me an email checking if my AD repository was the same as my domain (which it isn't!), as this would save having to edit inc files after an upgrade.  Step 9 of the following article: http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

Today I reset my demo appliance and tried the following:

• Configure the networking components of my Celestix WSA applaince
• Install Java, Active Perl, SP2 and SP2 Update 2
• Create an ActiveSync trunk
• Import my Exchange certificate
• Use an AD repository that is named the same my domain
• Modify the ASP file mentioned above
• Test - Success!
• Install SP2 Update 3
• Test - Success!
• Recreate my portal trunk for my applications
• Test - Success!

Now IAG SP2 Update 3 is working successfully in a new installation (albeit via SP2 Update 2, rather than straight to SP2 Update 3), I will try an in-place upgrade on my known working appliance.

Thanks for the email Uri, as it motivated me to look at this issue again!! :)

Testing IAG SP2 Update 3 - Part 2

Here is some useful information from the MS UAG Blog about IAG SP2 Update 3.

The table in the link is very useful at summerising what is and isn't supported.

Socket forwarding is not supported by any 64 bit Windows operating system, as well as Mac & Linux machines.  I have seen this with my Windows 7 64 laptop, which does not work with published RDP sessions, but can confirm that XP compatibility mode does work.

The Network Connector will not work with either 32 or 64 bit Windows 7 machines, as well as Mac & Linux machines.  I can confirm this as a customer and I have tested this, although I have yet to test a Windows 7 in XP compatibility mode with the Network Connector, but I suspect it will work.

Although this update was meant to be the "fix" for Windows 7 and IAG, I'm afraid there are still limitations.

IAG is dead.... long live UAG!

Testing IAG SP2 Update 3 - Part 1

I managed to get my hands on SP2 Update 3 for IAG v3.7 a week or so ago.

So far I've only managed to deploy this to my live environment, but with some good and bad results!

My current IAG platform is a Celestix WSA 4000, and it has been Service Packed and updated pretty much as and when these updates have been available.

As I'm a little wary of these things, I use the Celestix Last Good Version (LGV) feature, which allows me to take a snapshot of my appliance and save this to a Linux partition on the appliance. It takes around 15 minutes to make this snapshot, and around 10 minutes to rollback... if required!

My appliance hosts a portal with various applications such as OWA, Intranet, RDP, etc, as well as an ActiveSync tunnel for our mobile devices.

After the update was applied, the portal worked perfectly with both Windows 7 32-bit and 64-bit machines, but it broke my ActiveSync tunnel!

One of my authentication methods is Active Directory and it is used for both the Portal and ActiveSync tunnel. The authentication using AD was perfect on the Portal, but it failed for the ActiveSync tunnel. All the mobile devices said the wrong password was being presented.

No changes were made to the mobile devices and this impacted both Nokia E71 and Apple iPhones. Changing the password on the device made no difference, but we knew that the AD authenication should be working correctly as the portal works.

Rolling the appliance back to SP2 Update 2 using the LGV feature, allowed all the mobile device to authenicate again, even though someof these devices did not have their password changed.

Since then, I've managed to get hold of another appliance to test with, so Part 2 will continue tomorrow.....

Microsoft IAG SP2 Update 3

Information from Microsoft regarding: IAG SP2 Update 3

Once this has been tested by Celestix, it will be available for download from the webiste.

It will also give me a chance to test it in my lab as well.

Routing issues on IAG

I was asked this evening by a friend and customer why he was unable to remotely access a Celestix WSA appliance via a VPN, but able to access via an RDP session from one of the servers on the LAN.

There is a site to site IPSEC VPN between the two sites and the remote site subnet had been added into the Remote Management trusted subnets.

The issue lies with the Microsoft ISA 2006 component within the Celestix WSA appliance, that is used to protect Microsoft IAG.

First of all I would create a static route on the appliance. This can be done either by using the command line and adding a persistent route, using the jog dial on the front of the Celestix WSA appliance or using the Celestix Web UI (:10000) select "Network", then "Routing" and then "Static Routes", where you can create a new static route.

Once this is done, I would start up Microsoft ISA Server on the appliance, expand "Configuration", select "Networks", go to the "Networks" tab, right click for "Properties" of the internal network, select the "Addresses" tab, click the "Add Adapter" button, and select the "LAN" tickbox.
This will apply the all the routes that the LAN card can see, including the new static route(s). Once trusted, you will be able to access resources within the defined subnets, and ISA will be able to allow the traffic defined from the site to site VPN.


- Posted using BlogPress from my iPhone

IAG Logs - Extending?

A common issue raised by customers have been regarding how far back the IAG logs can go back.

I have posted in the past about how to use Syslog server with IAG, which will allow the logs to be stored elsewhere for longer, but you may still have issues with what or how much is being reported.

Extending your historical logs:

• In the IAG Configuration console, select the "Admin" menu and select "Event Logging"
• Select the "General" tab
• Change the "Queue Size" to 100
• Change the "Max Report Results" to 10000
• Click on "OK"
• Activate the IAG Configuration

Change the settings for report clean up:

• In the IAG Configuration console, select the "Admin" menu and select "Advanced Configuration"
• Change "Start Cleanup at:" to 10000
• Change "Stop Cleanup at" to 100
• Change "Number of Undeleted Files" to 100
• Click on "OK"
• Activate the IAG Configuration

You may need to wait up to 48 hours to see if these changes have helped, but these settings can be tweaked further to fine tune the logs for your reporting needs.

IAG SP2 Update 3?

Well I've had word that IAG SP2 Update 3 should be out in a month or so.

The components being addressed with this update, are that Windows 7 will be recognised correctly and 64-bit clients will be supported.

Obviously you have seen that I have documented a 32-bit Windows 7 workaround, but there are still issues with this when using certain applications. The only 64-bit client that can be made work is Windows 7, as long as your computer has the ability to run XP Compatibility Mode (which will mean that only specific processors are supported)

As soon as I see that update, I will get it installed and tested, as my work laptop is both Windows 7 and 64-bit..... you can see I like a challenge!!

Happy New Year for 2010!

And what a way to see in the New Year.

Currently where I live in the UK there is 3-4 inches of snow, which has made it very difficult to get off my driveway, let alone drive to work.

Fortunately I can work from home, thanks to a Celestix WSA appliance running Microsoft IAG!

I have access to my emails via OWA, intranet site, CRM server and Terminal Server.

This has allowed me to pretty much carry on as normal!

If you are stuck at home today, I hope you are working!! ;)

Microsoft CRM 4.0 on a non-IE browser and IAG

At e92plus we use Microsoft CRM 4.0 as our CRM system. It is a good product that allows a lot of flexibility, granularity and customisation, but the downside out of the box is that it will only work with an IE browser.

Not a major issue you may think as all the computers at work are all Windows devices.

As you can see in the previous post, we were in the process of replacing our mobile telephones at work, and as part of the rollout, I wanted to offer IAG via the mobile phone. I know it works(albeit very slowly) on a Blackberry and (pretty well with 3G) on iPhones.

Now if we were issuing mobile devices with internet access to the staff, I not only want them able to access the IAG, I also want to give them the ability to access our CRM system.

My choices were to look at Windows Mobile devices, but there is either a comprise on cost or functionality, or find a way to get CRM available on other browsers.

A bit of Googling from Neil Langridge (Marketing Manager for e92plus) turned up the following links:

http://blogs.msdn.com/crm/archive/2009/07/09/product-release-mobile-express-for-microsoft-dynamics-crm-4-0.aspx
http://weblogs.asp.net/gayanperera/archive/2009/07/10/dynamics-crm-4-mobile-express-released.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=F592EC6C-F412-4FD5-9A80-CD3BCBD26D8B&displaylang=en

After following the instructions on installing the 28Mb file, we then started testing.

I used Firefox, Safari, Opera and Chrome as my test browsers and they all worked perfectly. The view is slightly cut down, but we now have CRM on other browsers.

The next step was publishing this on IAG as a Generic Web Application (as I did for CRM on IE). Remember to use the server name, correct port number as well as the /m after the URL. I created an access policy to check the users browser, so that if they are using IE they have two icons (one for full blown CRM, and other for the "streamlined" version), and if they are using a non-IE browser they only see the "streamlined" version of CRM.

I have been playing with a number of mobile phones recently, and this works perfectly on Blackberrys, iPhones, Nokia and HTC Windows Mobile devices.

ActiveSync on IAG, with iPhones

The mobile phone contracts at work are up, so I have been investigating alternatives. We were previously using Blackberrys, but I've been investigating more cost effective options. Since the Blackberry server was installed, we have upgraded to Exchange 2007, which gives us the aability to us Push Mail/ActiveSync, something that was not an option on our previous mail server.

I was given a couple of test phones to trail ActiveSync on a Windows Mobile and a Nokia device.

First off, I had to ensure ActiveSync was enable on the Exchange server, and fortunately a "vanilla" build of Exchange 2007 haas it enable on install.

The thing was the create a NAT rule on my firewall to allow the ActiveSync traffic from the intenet to the Exchange server. This was only a temporary rule while I was testing ActiveSync worked, before the rule was removed again.

My security/paranoia head would not allow me to leave this rule in place, as I would not recommend to anyone to have a rule that allows direct connectivity from the internet to any mail server. (BTW that also includes email, as there are plenty of mail relay options, such as a Barracuda Spam Firewall - Blog post for another day!)

Here at e92plus as the saying goes "We eat our own dog food", where we use a Celestix WSA IAG appliance as a remote access solution.

The next step was for me to create way for the mobile device to connect to my Exchange server, without a direct connection. I configured one of our external IP addresses to NAT into the DMZ of our firewall. I then had to add an additional IP address on the external adapter of the Celestix WSA appliance to match the DMZ IP address of the NAT rule. I also created a new prefix for our domain, and mapped that to the external IP address I'm using.

Now on to IAG, create a new webmail trunk and selected ActiveSync. I defined the domain, selected the DMZ IP address, defined the details of my Exchange server, aand then activated the configuration.

I took the Trusted Root Certificate from my Exchange server and applied that to the IAG appliance.

From the mobile devices, I defined the domain, username and password. For the server address, I use the new IAG portal address.

It worked perfectly on the demo Nokia E63 and the HTC Touch, although the interfaces were different the information required to login was the same. This allows the devices to sync up emails, contacts, calendar and tasks.

After much deliberation, I decided that I wanted an iPhone as my mobile device. Although I am still waiting for the SIM to be activated, ActiveSync is syncing my email, contacts and calendar via my wireless network, so once the iPhone can get onto the O2 3G network, it will be working as it should!

For added security/paranoia, on the Exchange server I have also enabled mandatory passwords on the device, madatory encryption of the storage and the ability to remote wipe the devices, so pretty much the core features of a Blackberry server, at a much lower cost!

Web Monitor Logs

A common question I'm asked, is how can I keep my Web Monitor logs for longer. Ensure you have SP2 Update 1 installed for this feature.

Just feed the logs into a Syslog server, sounds easy...

• Start up the IAG Configuration application
• Select 'Admin' at the top and select 'Event logging'
• Select the 'Syslog' tab and enter in the details of your Syslog server

Sometimes, we just want an easy solution.... and here is one!

I've had a play with a freeware Syslog server called Syslog Watcher, which works very well with this integration, but would welcome any recommendations for Syslog software.

High Availability for IAG

After four hours on the train today, I spent a fair chunk of today configuring a pair of Celestix Load Balancers for an IAG deployment.

The only way to create IAG in a highly available configuration, is to put the IAG solution behind a front end load balancer. A common question I get asked is why do I recommend a pair of load balancers... well why would specify a solution with multiple application servers, only to place them behind a single load balancer and risk moving your single of failure from the application server, to the load balancing solution.

There are some simple instructions on how to configure the Celestix Load Balancers (CLB) and well documented in the manuals, but here are some headline points when configuring the solution for Direct Server Return (DSR), where the load balancer coming into the IAG solution, but outbound (as the name suggests) the IAG solution will go directly back to the client, rather than through the load balancer.

1. Configure the IAG external IP address to the be the virtual server IP address
2. Ensure DSR is selected in the advanced settings
3. Under the Healthcheck option for the target, ensure PING is off, but check TCPOpen ais enabled for 443,2,10
4. Ensure all IP addresses are unique, including gateways, servers, engines, etc.
5. Create an ISA rule to allow access from the CLB range to the Local Host, for port 443.
6. Create loopback adapters for the WSA appliance, ensuring that there is no gateway, and within advanced ssettings, the Interface Metric is set to 254
7. Ensure VRRP is enable, where both appliances have the same VRID, ensure the Master has a priority of 1 and the backup of 254, on a different network
8. Ensure the local host files that the server name points to the VIP

I had a pretty unique situation today, where four portals were configured on two IAG appliances, with virtual IPs and load balancers.

We ended up using 14 external IP addresses, VIP for each portal (4 external IPs), an external IP for each portal on each appliance (8 external IPs), and a unique IP for each load balancer (2 external IPs). It's very rare to have this many real IPs to play with, but the same principle would apply, if these IPs were internal ones behind a NAT'ing device, which would only have required 4 external IPs (one for each portal)

Ensure you understand the customer requirements and follow the manual.

Good luck with maaking your IAG solutions highly available! :)

ActiveSync on IAG - Certificate Issues

I realised the other day that I hadn't updated the issue that was encountered within this blog post about ActiveSync on IAG.

Well the issue turned out to be certificate related. The Exchange server was using a self signed certificate, so the trusted root certificate had to be added to the mobile devices.

There is some well documented information with regards to configuring Exchange 2003 ActiveSync using a self-signed SSL certificate.

Export the root certificate

1. On the Certificate Authority that issued the certificate to the Exchange server, open the Control Panel and double click Internet Options. NOTE - this guide assumes that you are using a Microsoft CA.
2. Click on the Content tab and then on the Certificates button.
3. Click on the Trusted Root Certification Authorities tab.
4. Locate the trusted root certificate for your domain. It is vital that the certificate be trusted rather than be listed under any other tab. Select the certificate and click on the Export button.
5. The Export Certificate Wizard will be displayed, click Next.
6. Select the option to export the certificate in DER encoded binary X.509 (.CER) format and click Next.
7. Enter a name for the certificate and specify where you would like the file saved. Click Next,
8. Finish and then OK.

Install the root certificate onto the client device

1. Now locate the .cer file created and copy it to your PDA via Microsoft ActiveSync to any folder on the device (for a Windows Mobile device), or using the appropriate synchronisation software for your device. Alternatively the file could also be saved to a memory card or transferred via Bluetooth.
2. On the PDA, open File Explorer and browse to the folder where you saved the certificate.
3. Tap on the icon for the certificate and tap Yes to install it when prompted.
4. On a Windows Mobile device, tap on Start → Settings → System → Certificates → Root and verify that the certificate is listed.
5. You are now ready to use Server ActiveSync securely, using your own SSL certificate.

There is also some useful troubleshooting information here: http://blogs.technet.com/edgeaccessblog/archive/2008/07/29/publishing-microsoft-activesync-through-iag-2007-part-2-of-2.aspx

IAG SP2 Update 2... finally!

There were a number of rumours that SP2 Update 2 would include 64 bit client support, but it seems it was just that... a rumour! The current rumour is that 64 bit client support will be available with SP2 Update 3, which is good considering we were always told that IAG would never support 64 bit operating systems. We can make Windows 7 64-bit work by using XP Mode (and detailed in the previous blog posting)

After QA testing from Celestix, IAG SP2 Update 2 is now available from the Celestix website.

The following issues are addressed with this update:

• Fixed erroneous IAG behavior when headers contain blank characters
• For trunks which do not publish an AAM application, the IAG Session cookie will be a site cookie instead of a domain cookie
• Fixed bug for supporting Citrix XenApp5 application
• Fixed parsing of text/html response Content-type (not binary) body using Chunked encoding type
• Fixed a failure occurring when using IAG’s Socket Forwarding client component on a Citrix terminal server
• Fixed a SharePoint Persistent Cookie Name Race Condition
• Fixed an Authorization Key Header memory Corruption while using an "Authorization Key" header
• Fixed a failure in the endpoint detection policy of AVG on the client computer (mistyped value in the detection policy expression)
• Fixed an Incorrect header removal when header is substring of another header
• Fixed Day Light Saving change leading to a deletion of Internalsite and Portal rules
• The communication between Windows Mobile 6.1 and Exchange 2007 SP1 has changed slightly due to the updating of the EAS protocol to EAS v12.1 – added support/fix for it
• Enabling above 2KB http header request by modifying the following registry key (MaxAllHeadersLen), to prevent SNT from throwing the following error to the client: "Allow http header block of a request to exceed 2KB and avoid SNT throwing an error"
• Fixed non English locales inconsistent encoding/decoding detection
• Fixed few issues related to FormLogin authentication
• Modified the rule-set that broke Java SSL Wrapper
• Added support iPhone and Blackberry support
• Fixed non-IE detection security issues

IAG SP2 Update 2 - Release_Notes

IAG SP2 Update 2 - Installation File

Does IAG work with Windows 7 (64 bit)?

After much experimenting with Windows 7 32 bit, you can see you are able to get Microsoft IAG to work with it, as can be been in one of my previous blog posts.

Now I hope we are all aware that 64-bit Windows operating systems are not supported by IAG. I know there were rumours of 64-bit support being released with IAG SP 2 Update 2, but that is not the case. We will discuss this update is a later blog posting.

Well I was fortunate enough to be provided with a new work laptop, which has a faster processor, bigger hard disk and more importantly 4GB RAM. I did initially install Windows 7 Enterprise 32-bit, but was disappointed to only see that 3GB was recognised by the OS (I would have lived with only 3.25-3.5GB being seen), so I bit the bullet and installed Windows 7 Enterprise 64-bit so that all the RAM is seen and can be used.

I know that Windows 7 64-bit will allow you to install applications as either 32 or 64 bit, so some things like Java should be installed twice to work with both 32 and 64-bit IE browsers, will specific 32 bit applications an be installed and used. That said, despite the workaround detailed for Windows 7 32 bit, this does not work in Windows 7 64 bit!

Luckily, Microsoft have a Windows XP Mode as a solution: http://www.microsoft.com/windows/virtual-pc/download.aspx

By installing Windows Virtual PC RC and Windows XP Mode RC, it will allow you to run a virtualised version of XP on your Windows 7 desktop. There are not additional licenses to consider, but you will need a processor with either Intel® Virtualization Technology or AMD-V™ feature turned on. I downloaded this application from the Intel website to check that my processor supported this feature from here: http://www.intel.com/support/processors/tools/piu/

I found these step by step instructions on Windows 7 XP Mode, which I found very useful: http://lifehacker.com/5245396/set-up-and-use-xp-mode-in-windows-7

Once installed and working, I also installed Avira Premium Security Suite software to remove the Microsoft Security Centre red shield.

I created a shortcut into the all users folder of the virtualised desktop, to my IAG website. This also placed the shortcut into the start menu of my Windows 7 Enterprise 64 bit. By clicking the link, it will start up an IE browser to my IAG appliance from the XP virtual environment, which gives a pretty seamless experience and I retain full IAG functionality.... phew!!!

IAG and Citrix XenApp 5

I had a fun day in Northampton on Monday and it was thanks to Wayne and Daryl for being such great company!

A seemingly straight forward IAG implementation, with straight forward requirements:

The applications required were OWA and Citrix XenApp, with RDP as a nice to have. The authentication methods were Windows AD and VASCO. Basic customisation and guidelines about housekeeping and DR.

We were replacing a SonicWALL SSL-VPN solution, which works in a single NIC configuration, so a number of services were needed from the appliance back into the LAN. We started by reviewing the firewall rules, removing the existing SonicWALL SSL-VPN rules, and creating a port 80 and 443 access on the WAN side of the Celestix appliance, as well double checking existing NAT rules to ensure that the external side was accessible through the internet.

The authenication methods were straight forward, but an oversight on the VASCO delayed the deployment, but after creating the backend to point at the IAG appliance, it was up and running!

OWA worked fine, but oddly RDP didn't work back to the blade servers, but did the Celestix appliance. Obviously a configuration on the blade servers need to be modified, but not really my field of expertise. Apparently this blade server setup can be configured with a web interface, so that could be published as a generic web app, when it's up and running.

The existing SSL certificate on the SonicWALL was moved to the Celestix appliance, after creating the CSR file from within IIS and getting the supplier to reissue the certificate. It was getting late, but the certificate wasn't working. We were unable to access the website, but we could with the self signed certificate. My gut feel was an issue with either the CSR file, or the creation of the CER file. We reverted back to the self signed certificate, but the customer was going to recreate the CSR file and get another reissue..... I found out today that this solved the issue!! (Phew!)

The reason for this blog entry was really due to the issue we encountered with the Citrix XenApp! Having deployed a number of Celestix appliances to work with Citrix Presentation Servers, I was quite confident that there really wouldn't be much difference with XenApp..... (How wrong I was!!)

I published the XenApp server and all seemed to work, but when you start up the application, we recieved the following message: Error: Cookies Required

My gut feel was that as XenApp worked before the issue lay with the configuration within IAG. After a bit of searching, we found this Citrix article: http://support.citrix.com/article/CTX117597

This article didn't really hit the nail on the head, but after a little experimentation, we found that this solved the issue, as detailed by the customer. As this software will not allow me to post Javascript code correctly, please find the details in the text file: XenApp5.txt