Using HLP files in Windows 10

It is amazing how some vendors of libraries in the automation industry still require you to read help files in the old Microsoft hlp format.  Trying to open such a file results EDGE to show you the following screen.
Image Error opening Help in WIndows-based programs: "Feature not included" or "Help not supported"

If you think you can download and install the version for Windows 8.1. you are wrong. But do not throw away your downloaded MSU-File (for Windows 8.1 x64 the name is Windows8.1-KB917607-x64.msu).

Start your command prompt as Administrator!

imageFirst extract the content of the MSU File to another directory:

md ContentMSU
expand Windows8.1-KB917607-x64.msu /F:* .\ContentMSU

Now we can extract the contained CAB-File:

cd ContentMSU

md ContentCAB

expand Windows8.1-KB917607-x64.cab /F:* .\ContentCAB

This will extract 279 files.  Depending on your culture and language settings we need to locate the right MUI-File. My language is german so I use “de-”. English folk use “en-“.

cd ContentCAB
dir amd64*de-*.
People who use the x86 variant need to run “dir x86*de-*.”
Navigate to the given path, in my case

cd amd64_microsoft-windows-winhstb.resources_31bf3856ad364e35_6.3.9600.20470_de-de_1ab8cd412c1028d0

Here we will find “winhlp32.exe.mui”. We need to replace %SystemRoot%\de-de\winhlp32.exe.mui with our new file:

takeown /f "%SystemRoot%\de-de\winhlp32.exe.mui"
icacls "%SystemRoot%\de-de\winhlp32.exe.mui" /grant "%UserName%":F
ren %SystemRoot%\de-de\winhlp32.exe.mui winhlp32.exe.mui.w10
copy winhlp32.exe.mui %SystemRoot%\de-de\winhlp32.exe.mui


 

takeown /f "%SystemRoot%\winhlp32.exe"
icacls "%SystemRoot%\winhlp32.exe" /grant "%UserName%":F
ren %SystemRoot%\winhlp32.exe winhlp32.exe.w10

cd ..

dir *.exe /s
Find the right path starting either with amd64 or x86 and navigate to it
cd "amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.20470_none_1a54d9f2f676f6c2"
copy winhlp32.exe %SystemRoot%\winhlp32.exe

Cheers
AndiP

Connect ZyWALL 35 with Azure VPN site to site

Some time ago I got an “old” ZyWALL 35 from an ex colleague and I always wanted to configure a site-to-site connection  to Azure. Although Microsoft only provides automatic scripts for the more advanced professional enterprise VPN gateways you can configure the device (if it is capable of VPN) yourself. This however can have some caveats like different expected key sizes, where you need to work around.

Hopefully this helps others with a ZyWALL35 to configure site-2-site connection and also those who also happen to have a different device.

I divided the article into the following sections:

  1. Setting up the virtual network environment in Azure
  2. Set Shared Key Length in Azure VNET to 31
  3. Configuring the ZyWALL35

May you succeed Smile.  Cheers AndiP!

1. Setting up the virtual network environment in Azure

My small private local network is operating in the following address range: 10.0.0.0/24 (10.0.0.0 – 10.0.0.255). I do want to have my Azure machines operate in the local VNET in the address range 10.0.1.0/24. So first of all we will create a virtual network in Azure for that purpose. Log into the Azure Management Portal. With the “+ NEW” button in the lower left corner we create a new virtual network.

image

image

image

Then hit the “Create”-Button. After Azure has created the virtual network we are presented with the Dashboard of our new virtual network. From there we add more Subnet’s.

image

Here we add another subnet (Do not forget to save the changes with the SAVE button!). I left some address range empty because this will be required by the Gateway-Subnet for the VPN Site-to-Site connection. Unfortunately you cannot add the Gateway-Subnet here in the new portal.

Name Address Space CIDR Block
Subnet-2 10.0.1.0/24 10.0.1.32/27

Now we need to configure our site to site connection by clicking into the VPN connection section. Inside the VPN Connection settings we select “Site-to-site” and give the local site a name (in our case “SpectoLogicLocalVPN”). As VPN gateway IP address we provide the public facing IP address of our ZyWALL 35 behind the internet modem. Finally we provide the address ranges of our local network we would like to connect. Due to a bug in the new Azure Portal you need to checkCreate gateway immediately”*.

It is also important to set the optional gateway configuration (see images below). Set the routing type to “Static”!

*Otherwise you will get the error “Deployment Failed”. The reason might be that you are not able to create the required Subnet-Gateway in the SubNet section. Once you created a site-to-site connection and remove it again you cannot remove the new created “Gateway Subnet” in the subnets, even though you would not require it any longer (another bug).

image    image

image

We can now see the new automatically added subnet “GatewaySubNet”:
image

Creating the gateway will take some time. (UP to 25 minutes)!

Once the gateway is created we will see the result here. The public gateway IP-Address will be needed later when we configuring our ZyWALL35 device!
image

2. Set Shared Key Length in Azure VNET to 31

Azure  uses SharedKeys that are bigger than the ZyWALL 35 supports. So we have to set the key size in Azure manually via PowerShell Script to change it to a smaller value. In our case “31”!

As David pointed out in the comment section there is now an easier way to achieve this.

We also need to switch to the old Azure Portal as the new portal does not allow the shared key management. Navigate to your VNET and you will find the “Manage Key”-Button in the Dashboard of the VNET:
image

Unfortunately the key is 32 characters long:
image

While we are at it. Although we gave meaningful names in our new Azure Portal the names of the local VPN Network and the Azure Network are completely differing from what we originally entered. I assume that this is because of the new “Resource Group” management. It makes things a bit more complex as we need the “real” names for our powershell script.

The VNETName can be found either in the new portal here Surprised smile:
image
or in the old portal here:
image

The local network name can be found in the new portal here Surprised smile Surprised smile Surprised smile:
image
or in the old portal here:
image

Now, after we somehow managed to find out the real names we can use them in our script below. Make sure you have imported the Azure publishing settings file and that you have imported the certificate either to your personal or local machine store. If not you need to know the Thumbprint of the certificate and assign it to the variable $mgmtCertThumb. If the certificate can be found in the store the script will locate it for you:

# Sets a vpn key with a smaller keylength
# © by Andreas Pollak / SpectoLogic

$subID = (Get-AzureSubscription -Current).SubscriptionId
$VNetName = „Group SpectoLogic_Resources SpectoLogicVPN
$VNetNameLocal = „9A10F5F7_SpectoLogicLocalVPN
$uri = „
https://management.core.windows.net/“+$subID+“/services/networking/“+$VNetName+“/gateway/connection/“+$VNetNameLocal+“/sharedkey“
$body = ‚<?xml version=“1.0″ encoding=“utf-8″?><ResetSharedKey xmlns=“
http://schemas.microsoft.com/windowsazure“><KeyLength>31</KeyLength></ResetSharedKey>‘;

#Identify Management Certificate Thumbprint
$mgmtCertThumb = $null

$mgmtCertCandidateCount = (Get-ChildItem -path cert:\CurrentUser\My\ | Where-Object {$_.FriendlyName -like ((Get-AzureSubscription -Current).SubscriptionName + ‚*‘)}).Count
if ($mgmtCertCandidateCount -ne 1)
{
$mgmtCertCandidateCount = (Get-ChildItem -path cert:\LocalMachine\My\ | Where-Object {$_.FriendlyName -like ((Get-AzureSubscription -Current).SubscriptionName + ‚*‘)}).Count
if ($mgmtCertCandidateCount -eq 1)
{
$mgmtCertThumb = (Get-ChildItem -path cert:\LocalMachine\My\ | Where-Object {$_.FriendlyName -like ((Get-AzureSubscription -Current).SubscriptionName + ‚*‘)} | Select-Object -First 1).Thumbprint
}
else
{
echo „Could not locate the certificate thumbprint of the corresponding azure
management certificate!“
echo „Please make sure to install the azure management certificate in the ‚personal‘
folder “
echo „of either the ‚local machine‘ or ‚current user‘ certificate store on your
machine! “
echo „The friendly name of the certificate must start with the SubscriptionName to be
automatically detected! “
}
}
else
{
$mgmtCertThumb = (Get-ChildItem -path cert:\CurrentUser\My\ | Where-Object {$_.FriendlyName -like ((Get-AzureSubscription -Current).SubscriptionName + ‚*‘)} | Select-Object -First 1).Thumbprint
}

$headerDate = ‚2012-03-01‘
$headers = @{„x-ms-version“=“$headerDate“}

Invoke-RestMethod -Uri $uri -Method Put -Body $body -Headers $headers -CertificateThumbprint $mgmtCertThumb

After running the script we can now acquire our key and store it for later when we configure our ZyWALL35. It should be 31 characters long now. ATTENTION: DO NOT RECREATE THE KEY. Otherwise it will be 32 characters long again. Use the script again to regenerate the key!

3. Configuring the ZyWALL35

Finally we get to configure our ZyWALL35. First we download a script as text file where we can read the basic configuration settings like HASH, Encryption Algorithms,…

image

We log on to the ZyWALL35 Configuration Website and select VPN from the “Security”-Menu.

image image

Configure the Global Settings as shown in this screen shot:
image

Select the tab “VPN Rules (IKE)”.  Add a new gateway policy by clicking on the “add new gateway policy” button (image).

In the section “Property” we name our local VPN Gateway Policy “SpectoLogicVPNGWPolicy”. Also make sure NAT Traversal is checked!

In the section “Gateway Policy Information” we need to provide our local public IP address as well as the public Azure VPN Gateway address. So under “My ZyWALL” we provide our local public IP address:
image

Under “Primary Remote Gateway” we provide the public Azure Gateway IP-Address. In our home scenario we leave IPSec High Availability unchecked.
image

Since I have not set up any PKI Infrastructure I go for the simple “Pre-Shared-Key” Authentication. Note that the ZyWALL 35 only supports Pre-Shared-Keys that are 31 characters long. This conflicts with Azure, per default not allowing smaller key sizes. See section “Set Shared Key Length in Azure VNET to 31 “ above on how to change that.
image

We leave the extended authentication settings untouched (uncheck “Enable Extended Authentication”)  and configure the IKE Proposal.
image

Finally we hit apply. Back in the “VPN Rules (IKE)”-Tab  we select “Add Network Policy”:
image

We name the VPN Network Policy “SpectoLogic VPN Net Policy” and set it to active (check that checkbox!). Also check “Nailed-up”!
image

The linked Gateway Policy should already appear populated:
image

In the section “Local Network” we select “Subnet Address” from the “Address Type” dropdown and we provide the starting IP address in our local network and define the subnet mask for the range.
image

Now we also need to configure our remote network under the “Remote Network” section. Again we select “Subnet Address” from the “Address Type” dropdown and provide starting IP address and subnet mask:
image

For the IPSec Proposal select the same values we already used for the VPN Gateway Policy (Exception: PFS set to NONE!):
image

So we end up with:
image

To Connect / Disconnect the VPN in the new portal click on the following elements:
image
You also can pin the last element to your dashboard by right clicking on the name of the VNET in the middle section:
image

Finally we can enjoy our site-2-site connection (New Portal / Old Portal):

imageimage