FIM ECMA 2 Connector using the ConfigParameterDefinition.CreateFileParameter Method and how to Decode the Value

When you are developing a custom ECMA 2 based Connector for FIM, you can choose between different ConfigParameterDefinitions to use in the Connectivity, Global, Partition and Run Step ConfigParameterPage. One of them is the CreateFileParameter, which allows you to select (browse for) a file and then stores the content of that file as a Base64 string. You can find a list of all available methods here http://msdn.microsoft.com/en-us/library/windows/desktop/hh858152(v=vs.100).aspx.

And here’s an example:

switch (page)
{
caseConfigParameterPage.Connectivity:
configParametersDefinitions.Add(ConfigParameterDefinition.CreateLabelParameter("Text"));
configParametersDefinitions.Add(ConfigParameterDefinition.CreateStringParameter("User", ""));
configParametersDefinitions.Add(ConfigParameterDefinition.CreateEncryptedStringParameter("Password", ""));
configParametersDefinitions.Add(ConfigParameterDefinition.CreateDividerParameter());
configParametersDefinitions.Add(ConfigParameterDefinition.CreateLabelParameter("Text"));
configParametersDefinitions.Add(ConfigParameterDefinition.CreateFileParameter("Attributes"));
break;
}

Now, the question is: how can you access the content of the previously selected file? I spent some time to find a working solution, as the way how the content is encoded with Base64 is not described (at least, I haven’t found it on MSDN or TechNet).

In my case, I have a XML file, which I have to use as part of the GetSchema() method. Accessing the Value property returns the Base64 string:

configParameters["Attributes"].Value;

Therefore, you have to decode it. However, there is one important thing you have to consider: the Byte Order Mark (BOM). Without dealing with the BOM, parsing the decoded string as XML will fail with a “Data at the root level is invalid. Line 1, position 1.” exception. Fortunately, there is a simple solution to get rid of the BOM:

String.Trim().Trim(newchar[] { '\uFEFF' });

After this step, you are able to successfully parse the decoded string and continue to work with the XML, for example by using the XElement class:

var pAttributes = from p inXElement.Parse(decodedString).Elements("Attribute")
select p;

 

DirectAccess, IPHTTPS interface disabled and ICMP Destination Unreachable Messages

Yesterday, I worked on a very special DirectAccess (DA) issue. Especially the status of the IPHTTPS interface was really confusing, and that’s the main reason for this blog (to share my experience with the global community).

The Windows Server 2012 DA server is installed behind a outsourced firewall doing NAT, and the outsourcing provider has set the MTU size of the firewall’s Interface to lower than 1500, which is the default value for the network adapter of a Windows Server. Sure, we didn’t knew that at this point. :-)

On the client side, Windows 7 is used, and because the DA server is behind a NAT device, IPHTTPS only is used. However, the client was never able to connect and create the IPsec tunnels, The IPHTTPS interface status was always disabled (error code 0×0), but switched to 0x274c after ~5 minutes. Based on this error code, we decided to install NetMon 3.4 on the DA server to capture the network traffic. And here’s what we have seen:

  • The DA server has reset (flag R) the TCP connection to the DA client after a timeout of ~10s, after the IPHTTPS handshake
  • There were many ICMP destination unreachable messages with the status ‘fragmentation needed’

So, after a call with the firewall provider (where we learnt that they have set a specific MTU size), we changed the MTU size of the DA server’s external Interface to 1450, and lo and behold, the IPHTTPS interface status was no longer disabled and the client able to connect!

So my conclusion: The IPHTTPS interface status is misleading when there is a misconfiguration of the MTU sizes between the DA server and a firewall. So, whenever the interface is disabled (and you haven’t done that manually with intent), you should have a look at the MTU configuration…

A hotfix rollup package (build 4.1.3441.0) is available for Forefront Identity Manager 2010 R2

The latest hotfix rollup package for FIM 2010 R2, released on April 18th, fixes issues in the FIM Synchronization Service (plus two new Features), FIM Certificate Management, Self-Service Password Reset portal and the BHOLD suite. As usual, you can find more Information about the rollup package on TechNet, including the download link:

http://support.microsoft.com/kb/2832389

Windows Server 2012 Unified Remote Access Planning and Deployment – Review of Chapters 3, 4 and 5

Just finished chapter 3, 4 and 5 of the book Windows Server 2012 Unified Remote Access Planning and Deployment. It’s still very enjoyable and informative, and a great resource for everyone that wants to ramp up with DirectAccess or wants to strengthen the existing skills.

Chapter 3 addresses those basic services and components that are important for a DirectAccess deployment, for example Group Policy Objects or the Public Key Infrastructure. So that chapter gives you a good understanding of it. Chapter 4 and 5 are less theory than practice, and cover the installation and configuration of the Unified Remote Access role in a single server, load balanced and multisite deployment. Both chapters including some tips and tricks, which you cannot find on TechNet for example.

However, I have found some typos or wrong information, which I would like to rectify:

  • Page 143, with an external hardware load balancer, you can cluster together up to 32 nodes and not only 8. Source: http://technet.microsoft.com/en-us/library/jj134166.aspx)
  • Page 144, it is not always required to configure your network with IPv6 addresses during the setup, it depends on your infrastructure. For example, if you want to use an external just in front of the URA servers, no IPv6 addresses are required. I
  • Page 149, NLB should start automatically and manually start it should not be required.

Tips and Tricks with Windows Server 2012 DirectAccess and Windows Network Load Balancing

The last two days, I worked on a Windows Server 2012 (WS2012) DirectAccess (DA) deployment with enabled load balancing, where Windows Network Load Balancing (NLB) is used. As we had some issues during the setup of load balancing with Windows NLB, I want to share some tips and tricks with you:

  1. Update the drivers of all network adapters – it’s very important to install the latest available drivers for the network adapters installed in the WS2012 DA server. We had an issue with setting the Virtual IP (VIP) and Dedicated IP (DIP), which disappeared after we installed the latest driver from the network adapter manufacturer (not from the download page of the server manufacturer).
  2. Plan the VIPs and DIPs carefully – the WS2012 Load Balancing setup wizard automatically “converts” the existing IP addresses to VIPs, and you have to define the new DIPs. The WS2012 Remote Access Management console does not allow you to change the VIPs, so it is not possible to add a new one. And VIPs added with the NLB Manager are removed magically at some time (in our case after we rebooted one of the cluster nodes).
  3. If you want to use Teredo, configure it before enabling loading balancing – more or less the same story as in point 2. You cannot add new VIPs to a DA cluster. So, if you want to use Teredo, make sure that your setup fulfills the requirement before enabling the load balancing. Having said that, make sure that 2 public consecutive IPs are configured on the WS2012 DA server. Otherwise you have to disable the load balancing, change the IP configuration and reconfigure the DA cluster from scratch.
  4. Misconfiguration and the wrong subnet mask – when we added the 2nd WS2012 DA server to the DA cluster, the subnet mask of this server was always wrong and a misconfiguration warning was displayed in the NLB manager. For example, instead of 255.255.255.240, the configured subnet mask was always 255.255.255.15. Fortunately, you can edit the subnet mask in the NLB manager.

System Center 2012 Monitoring Pack for Remote Access 2012

In case you have not seen it already, Microsoft published the System Center Monitoring Pack for Windows Server 2012 Remote Access, which includes DirectAccess and Routing and Remote Access Service (RRAS) VPN.

You can download the monitoring pack here at http://systemcenter.pinpoint.microsoft.com/en-US/applications/system-center-2012-monitoring-pack-for-remote-access-2012-12884953389.

Software-based Networking Solution for Windows Server 2012 Hyper-V

Agreed, the announcement is not new, but still worth spreading it out. Vyatta, the famous Linux-based software networking solution, is available in version 6.5, which integrates support for WS2012 Hyper-V and several enhancements to its routing and security functionality. But of course, the support for Hyper-V is the most important enhancement!

You can find more information here in the announcement at http://www.vyatta.com/news-events/press_releases/2012/vyatta-adds-hyper-v-support-expands-advanced-routing-capabilities.

Multiple Windows Server 2012 Remote Access Servers in the same IP Subnet and DirectAccess Multisite

If you want to install multiple Windows Server 2012 (WS2012) Remote Access servers in the same IP subnet and want to setup a DirectAccess multisite deployment, you have to disable the duplicate address detection feature of Windows for the internal network interface. Otherwise, the DNS64 address cannot be set on any of the additional servers, and therefore internal resources are not accessible through DirectAccess (because DNS is not working, as the DNS64 address is not configured on the WS2012 Remote Access server). However, the address detection feature can easily be disabled by executing the following PowerShell command:

Set-NetIPInterface –InterfaceAlias (Get-RemoteAccess).InternalInterface –AddressFamily IPv6 –DadTransmits 0

Run that PowerShell before you add another server to the multisite deployment…