Forefront UAG 2010 SP2 released


I just noticed Forefront UAG 2010 SP2 has been released as of last week 06/08/2012.

Looks to contain lots of fixes as well as improved support for Apple IOS 5.x and Android 4.x devices.

See release notes from UAG product blog here or you can just download it here.

Warning — This update requires all your clients to install  a new version of the ActiveX endpoint component plugin. If you don’t want your clients updating the ActiveX components or you push out the UAG components via msi then do not deploy this update!

Updated 21st August 2012:

My experience with the upgrade was not completely painless.

I installed the patch on my secondary UAG server in about 3 minutes and rebooted. No worries there.

I then installed the patch on my primary UAG server – the patch took a good 20 minutes to install and after the reboot (which isn’t necessary but I don’t trust Windows), when logging into to test, my trunk web pages were not being displayed correctly. I was getting the usual ‘Server Error in SecureTrunk application’ message.

What else to do except stop the World Wide Web Publishing service, rename the \von\Conf\WebSites folder and reactivate my trunk confiugration from within UAG Management Console to recreate the trunk web site folders to try fix.

Still didn’t work.

I suspected my old friend – the group policy security settings forcing FIPS compliance: ‘System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing.’ I disabled this via GPO and rebooted. This seemed to resolve the issue.

Why had this setting changed? Not sure – my web.config file looked unaltered – it was still set to use 3DES encryption which is FIPS compliant.

Not sure but I’m going to find out!

Advertisements

SRM doesn’t support RecoverPoint point in time fail over?


I have to admit I was a little surprised when I found out from EMC that SRM does not support Recoverpoint Point in Time fail over.

Funny how VMware couldn’t tell me this? They just passed the buck to EMC… typical!

What’s the point of purchasing a product like EMC Recoverpoint if you cannot use it to its full potential? Well, that’s not entirely true, you can, you just have to do it outside of SRM!

Maybe SRM 5 has spoilt me a little. It does what it is supposed to do extremely well, but I just assumed the SRM RecoverPoint SRA would integrate with RecoverPoint’s image access and allow you to pick a previous point in time if required during a failover.

Alas, this is not the case. You cannot pick a point in time with SRM, it always uses the latest image only.

This is a feature request for SRM, VMware employees if you are reading this: When I perform a Test Failover I would like the ability to pick a previous point in time if required, before the failover commences.

What if you have to performed a Disaster Recovery failover and your latest image is corrupt. How do you then roll back to a previous journal entry in your Recovery Site?

These are some of the scenarios I don’t quite fully understand and I’m going to do some testing to see if I can combine some SRM and RP steps to at least partially automate the process – the thought of using RP natively, enabling image access,  mounting LUNS in the recovery site, rescanning hosts, registering VMs in vCenter, etc has really put me off using RecoverPoint’s point in time features.

More on this to follow.

How to modify NAS-IP-ADDRESS attribute on Forefront UAG


By default the UAG will pass 127.0.0.1 in the NAS-IP-ADDRESS attribute.

RADIUS NAS-IP-Address Attribute is really useful as it allows an arbitrary IP address to be used as RADIUS attribute 4, NAS-IP-Address, without changing the source IP address in the IP header of the RADIUS packets.

Why would you want to change this from 127.0.0.1?

Some older RADIUS servers need the NAS-IP-ADDRESS attribute to match the source IP address header in the RADIUS packets, so modifying this attribute to the IP address of your internal interface on the UAG will fix this problem.

  1. My repository in UAG is called ‘Identityguard’
  2. Copy \von\InternalSite\samples\respository_for_radius.inc to repositoryname.inc (in my case IdentityGuard.inc) into the \von\InternalSite\inc\CustomUpdate\ folder.
  3. Then if you want to update the NAS-IP-ADDRESS field to the UAG internal interface, set: param_ip.Value = “10.x.x.x”

This is documented in this KB article – KB960302.

Alternatively if you are trying to integrate the UAG with Risk Based Authentication features included with Entrust IdentityGuard Enterprise Server, you will want the UAG to pass remote access client’s IP addresses in the NAS-IP-ADDRESS field.

Here’s how:

  1. My repository in UAG is called ‘Identityguard’
  2. Copy \von\InternalSite\samples\respository_for_radius.inc to repositoryname.inc (in my case IdentityGuard.inc) into the \von\InternalSite\inc\CustomUpdate\ folder.
  3. If you want to set the NAS-IP-ADDRESS field to the Client’s IP address set:  param_ip.Value = g_source_ip

and client source IP addresses will be passed through to the IdentityGuard Server now.

What to do if a reprotect fails in SRM… Protection group has protected VMs with placeholders which need to be repaired


I had this issue today where a reprotect failed after a Planned Migration. I thought it was worth running through what I had to do to resolve the issue without performing a ‘Force Cleanup’ Reprotect as there is currently no KB article describing this workaround.

In my case the planned migration went ahead as planned without issues. All VMs were powered on at the Recovery Site and the Recovery Plan completed successfully.

When it came to the reprotect however, the reprotect failed on Step 3 ‘Cleanup storage’ with the error ‘Error – Protection group ‘xxx’ has protected VMs with placeholders which need to be repaired.’

The reprotect cancelled and when I looked at the protection group, only 3 of the 11 virtual machines were in an ‘OK’ state. The other 8 had a number of different error messages, including SRM Placeholder datastore could not be accessed, insufficient space, etc. Nothing that seemed to correlate.

I tried the reprotect again, without the force cleanup option and it failed again, so I removed protection from all the VMs with errors, and ran the Reprotect again. This time it worked fine after a few tense minutes.

To get SRM back to a protected state, I then had to delete from disk the placeholder VMs in the Recovery Site and manually reprotect all the VMs.

 

Hope this helps…