Updating Azure Virtual Network to use point-to-site feature

Scott recently announced support for point-to-site VPN connections into Azure – awesome! But what might not be so clear is how to enable it on your existing Virtual Network configuration – because you can’t make changes (at least through the UI) to your virtual network after it has been deployed and is in use.

Fortunately, there appears to be a workaround.

1) Export your existing configuration (go to the Networks view in the Azure management portal, and click the Export button).

2) Modify the XML with the following. Firstly, you need to add a new “GatewaySubnet” entry, which should be inside the address space of your virtual network. You then need to add a “VPNClientAddressPool” node, with an AddressPrefix outside the address space of your virtual network.

<VirtualNetworkSite name="XNetwork" AffinityGroup="NorthEurope">
  <AddressSpace>
    <AddressPrefix>10.4.0.0/16</AddressPrefix>
  </AddressSpace>
  <Subnets>
    ...
    <Subnet name="GatewaySubnet">
      <AddressPrefix>10.4.1.0/24</AddressPrefix>
    </Subnet>
  </Subnets>
  <Gateway>
    <VPNClientAddressPool> 
      <AddressPrefix>10.0.0.0/24</AddressPrefix> 
    </VPNClientAddressPool>
    ...
  </Gateway>
</VirtualNetworkSite>

3) Go to Networks | Virtual Network | Import Configuration and re-upload your XML file.

Sorted! Now you can continue to configure point-to-site connectivity from the network dashboard as described here.

Configure Visual Studio 2012 to use 64 bit version of IIS Express

By default Visual Studio (as a x86/32bit process) will always launch the 32bit version of IIS Express. If you have components that specifically require running under 64bit, you can can configure Visual Studio 2012 to use IIS Express x64 version by setting the following registry key:

reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects /v Use64BitIISExpress /t REG_DWORD /d 1

You should note that this feature is not supported and has not been fully tested by Microsoft – you have been warned!

Cisco VPN Client for Windows 8

There isn’t currently a version of Cisco’s VPN client that supports Windows 8, and after installation I received an error message complaining that the “VPN Client failed to enable virtual adapter.”.

Fortunately, there is a way to get this “legacy” VPN client to work, with a small registry change:

  • Open up the registry editor by typing regedit in Run prompt
  • Browse to the Registry Key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\CVirtA
  • Edit the DisplayName entry and remove the leading characters from the value data upto “%;” i.e.
    • For x86, change the value data from something like “@oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter” to “Cisco Systems VPN Adapter”
    • For x64, change the value data from something like “@oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter for 64-bit Windows” to “Cisco Systems VPN Adapter for 64-bit Windows”

Then you can try connecting again – this did the trick for me.

Disabling Chrome’s Metro app in Windows 8

At time of writing, if you replace IE with Chrome on Windows 8 then Chrome installs both a desktop and a Metro version of itself. Personally, as most of my time is spent in the desktop, I’d rather Chrome just always opened there.

There’s currently an open issue on the chromium website, but in the meantime there’s a relatively simple workaround. You just need to open up regedit, navigate to

HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command

and then rename/remove the DelegateExecute entry. Then Chrome will always open in desktop mode – problem solved!

MSDTC gotcha’s with Virtual Machines

Setting up some new infrastructure with a web and seperate db tier, I was hit with the usual MSDTC woes.

Error messages progressed bit by bit as I opened things up:

Attempt #1: The partner transaction manager has disabled its support for remote/network transactions.

Attempt #2: Network access for Distributed Transaction Manager (MSDTC) has been disabled. Please enable DTC for network access in the security configuration for MSDTC using the Component Services Administrative tool.

Attempt #3: The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn’t have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.

I couldn’t get past the final error though. DTCPing is a very useful tool if you’re struggling with this, along with this TechNet article on what settings should be in place. One warning popped up that sent me in the right direction:

WARNING:the CID values for both test machines are the same while this problem won’t stop DTCping test, MSDTC will fail for this

As it happens, both machines were from an identical VM clone, and therefore had identical “CID” values. You can check this by going to HKEY_CLASSES_ROOT\CID. Look for the key that has a description of “MSDTC”.

Having found Brian’s article who had done the hard work previously, this set me on my way – essentially you just need to uninstall and reinstall MSDTC on both of the machines. The following worked for me:

  1. Run “msdtc -uninstall” (from an admin prompt)
  2. Run “msdtc -install”
  3. Reconfigure MSDTC again from Component Services\My Computer\Distributed Transaction Coordinator\Local DTC (right click, properties)

And off you go… (don’t forget to enable the predefined DTC rules for local hosts in advanced firewall settings too)

Migrating old websites & Rewrite maps in IIS 7

If you’re migrating to a new website and need to map old IDs to new IDs, I’ve just discovered that the UrlRewrite plugin in IIS has a great feature I hadn’t come across before called rewriteMaps. This means instead of writing a whole bunch of indentical looking rewrite rules, you can write one – and then simply list the ID mappings.

The syntax of the RegEx takes a bit of getting used to, but in our case we needed to map

/(various|folder|names|here)/display.asp?id=[ID]

to a new website url that looked like this:

/show/[NewId]

You can define a rewriteMap very simply – most examples I saw included full URLs here, but we just used the ID maps directly:

<rewriteMaps>
  <rewriteMap name="Articles">
    <add key="389" value="84288" />
    <add key="525" value="114571" />
    <add key="526" value="114572" />
  </rewriteMap>
</rewriteMaps>

You can reference a rewriteMap using {MapName:{SomeCapturedValue}}, so if SomeCapturedValue equalled 525 then you’d get back 114571 in the list above.

Because we’re looking to match a querystring based id, and you can’t match queryString parameters in the primary match clause, we needed to add a condition, and then match on that captured condition value instead, using an expression like this:

http://www.newdomain.com/show/{Articles:{C:1}}/

The final rule XML follows:

<rule name="Redirect rule for Articles" stopProcessing="true">
  <match url="(articles|java|dotnet|xml|databases|training|news)/display\.asp" />
  <conditions>
    <add input="{QUERY_STRING}" pattern="id=([0-9]+)" />
  </conditions>
  <action type="Redirect" url="http://www.developerfusion.com/show/{Articles:{C:1}}/" appendQueryString="false" />
</rule>

Debugging Powershell and Psake commands and parameters

Getting commands and parameters in Powershell and Psake can be pretty troublesome at times. The echoargs helper from the PowerShell Community Extensions can be a lifesaver. If, for instance, you are calling

msbuild.exe /t:Build /p:SomeTroublesomeParametersHere

if you swap msbuild for echoargs (after placing the extensions in C:\Windows\System32\WindowsPowerShell\v1.0\Modules and calling Import-Module pscx), then you’ll see the exact parameters being passed to the executable:

Arg 0 is </t:Build>
Arg 1 is </p:SomeTroublesomeParametersHere>

However, to make it easier for those dipping into our build scripts, I decided to create a wrapper function so that we would always output parameters to the external functions we call to the console for debugging purposes.

function Invoke-EchoCommand
{
    $cmdName = $args[0];
    $remainingArgs = $args[1..$args.Length]
    Write-Host "Executing $cmdName" -ForegroundColor darkgray
    & "$base_dir/tools/build/echoargs" @remainingArgs | Write-Host -ForegroundColor darkgray
    exec { & $cmdName @remainingArgs } # using exec helper in PSake
}

You can then replace any calls to exec with

Invoke-EchoCommand msbuild.exe /t:Build /p:SomeTroublesomeParametersHere

and you’ll get some helpful debug information over how the parameters were actually passed. The only nifty bit in the function is that it uses the first parameter as the command name, and then passes all remaining arguments on to the executed command.

Determining if an assembly is x64 or x86

After encountering a strange deployment issue today, eventually it was tracked down to an x86 assembly being deployed to a x64 process. There’s a tool included with Visual Studio called corflags that was helpful here. Open up a Visual Studio command prompt, type corflags.exe assemblyname.dll and you’ll see something like this:

Version : v4.0.20926
CLR Header: 2.5
PE : PE32
CorFlags : 11
ILONLY : 1
32BIT : 1
Signed : 1

for a 32 bit assembly, and

Version : v4.0.20926
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1

for a “Any CPU” assembly. There’s more details on everything these fields mean in Brian Peek’s excellent blog post on the topic.

Unblocking downloaded DLLs

I find myself regularly forgetting to unblock zip files of various projects (when I’m not using NuGet) and then getting .NET errors around untrusted assemblies. To bulk unblock all files in a directory, simply