September – 2010 – B4Z.co.uk

ISA To TMG – Site To Site IPSec VPN

September 18, 2010 Leave a Comment

I recently encountered an issue creating a site to site IPSec VPN tunnel between Microsoft ISA Server 2006 and Microsoft Forefront TMG 2010. The IPSec tunnel itself would establish correctly, however I found I could only contact resources at either end of tunnel if I initiated the connection from either the ISA or TMG servers themselves. If I attempted to send a PING command from a workstation on the ISA internal network, to a workstation on the TMG internal network it would simply timeout. CIFS, FTP and web traffic all suffered the same fate.

After creating the topology in a test virtual environment, I was able to replicate the exact same issue I was experiencing in the production environment. After a few days of performing traces, I contacted Microsoft Partner Support to ask if they had experienced this problem before. They informed me they had and it was addressed in post SP1 hotfix KB 980674. Even though my TMG toplogy did not contain an NLB, and the KB article specifically states the hotfix is for NLB topologies, it resolved my issue never the less. To ensure your ISA to TMG IPSec site to site VPN works correctly ensure the following actions are performed:

1. Ensure the name of the IPSec VPN is the same on both the ISA and TMG servers. For example, in the site to site VPN wizard on your TMG server, if you name the tunnel “IPSec VPN” this name must also be used when you set the tunnel up on the ISA server.

2. Change the IPSec Phase 1 and Phase 2 security settings on your TMG server to match those on your ISA server. By default, TMG uses a higher level of IPSec encryption than ISA. You can obtain the IPSec security settings by reviewing them in the properties of the site to site VPN tunnel as shown in the below screenshot.

3. Ensure the network address ranges you assign in the site to site tunnel wizard are correct. For example, if you are setting up the VPN connection on your TMG server and the ISA servers internal network address range is 172.16.10.0 – 172.16.10.255 you must specify the network in the tunnel wizard as 172.16.0.0 – 172.16.255.255, otherwise traffic will not pass over the tunnel correctly.

4. Ensure your ISA and TMG servers are fully service packed and all hotfixes are applied, in particular hotfix KB 980674 on your TMG server, even if you do not have an NLB configuration.

Hopefully this help will solve any cross platform IPSec VPN issues you are experiencing.

VMware Capacity Planner – Collector Access Denied

September 12, 2010 Leave a Comment

I recently experienced a strange issue when implementing the VMware Capacity Planner at a customer site. Once the collector software had been installed and I attempted to run the initial inventory of my target servers, the following error message was displayed in the capacity planners task pane.

ERROR: An unexpected error occurred! Module = VMware Capacity Planner Collector Function = ProcessJobs Source = vcpCollector Error = Permission denied(70:0:1000070)#

On first glance I thought this was an issue when querying a target server though either the remote registry or WMI. Some further research led me to VMware Knowledge Base article KB 1001396 which detailed the error listed above. Unfortunately the article detailed that this error is usually reported when running the collector on a Windows Server 2003 platform that is utilising hardened security methods, I was however using a Windows XP Professional machine as my collector platform. Ironically the suggested solution for this error in the VMware KB article is to install the collector on a Windows XP workstation.

After removing anti-virus applications, GPO’s and several software re-installations later a colleague recommended resetting the local security policy on my Windows XP collector workstation back to default, in the eventuality the security policy applied via GPO had not removed correctly. After running a secedit command to restore the local security policy and re-running the inventory task in the capacity planner everything was now working as expected. To reset the local security policy of a Windows XP workstation, perform the following steps:

1. Click Start and select the Run menu item.

2. In the Run dialog box type CMD and click ok.

3. In the command prompt window type the following entry, without quotations, and press return on your keyboard:

“secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose”

4. Once you have pressed return on your keyboard you should then receive a “Task is completed” message and a warning message that an item could not be completed. You can safely ignore this message.

5. In the Capacity Planner software re-run the initial inventory task, and you should now see that the access denied error is no longer displayed.

For more information on resetting the local security policy of any Windows based operating system, please see the following URL: http://support.microsoft.com/kb/313222

OCS 2007 R2 – External Audio/Video Conferencing Issues

September 9, 2010 1 Comment

The successful implementation of external audio/video conferencing in Microsoft OCS 2007 R2 appears to be an issue that many people face when deploying the product. I too have experienced this issue and this post will detail both the errors and resolutions put in place to enable external A/V conferencing on an OCS 2007 R2 Standard Edition deployment with a Consolidated Edge server. The implementation item’s listed in this post assume you have a firewall product in front of the Consolidated Edge server that is performing both resverse proxy and NAT features.

1. External A/V Conferencing – Errors

When testing multiparty A/V conferences I experienced the following errors. These errors were produced when adding a third participant to an existing two party (peer to peer) A/V conference.

Cannot perform the selected action. This action may not be permitted by the conferencing service. Please try again. If the problem persists, please contact your system administrator.

The call was disconnected because you stopped receiving audio from [email protected]. Please try the call again.

An error occurred while trying to take the call off hold. If the problem persists, contact your system administrator. More details (ID:500)

An error occurred while trying to start the conference. More details (ID:52031)

As you can see, there is not a single persistent error that is produced which unfortunately makes troubleshooting slightly more difficult. After spending some time performing SIPStack traces and reviewing Communicator logs via the Snooper Tool, I narrowed the errors down to a firewall and consolidated edge server configuration issue.

2. External A/V Conferencing – Resolution Items

The item’s listed below resolved the external A/V conferencing issues I was experiencing. These steps are also included in the official Microsoft production documentation for Consolidated Edge server deployments.

A/V Edge Service Name Resolution– Configure the Edge Server to resolve the FQDN associated with public A/V Edge service to the publicly routable IP Address, not it’s internal NAT’d IP address. For example, if your A/V Edge service has a public IP address of 100.200.255.255 and a NAT’d IP address of 10.45.16.5, if you run a command prompt from the Edge Server and type ping av.externaldomain.co.uk it must return 100.200.255.255. A good way of achieving this is making a hosts file entry on your Edge Server to force the FQDN to resolve to the public IP address.

A/V Edge Service NAT– Assuming you have a firewall product (ISA/TMG) in front of your Consolidated Edge server that is performing NAT, configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox. This setting can be found under the Edge Servers properties dialog box.

Firewall Access Rules– Configure your firewall product with the following protocol definitions to allow A/V traffic to be passed to your Consolidated Edge server. Once you have performed this, create a new server publishing rule that targets your Consolidate Edge server and utilises the protocols you have just created. Please note the below protocol definitions target ISA/Forefront TMG deployments specifically. A very useful article on performing this can be found here.

Protocol name	AV TCP In
Protocol type	TCP
Direction	Inbound
Port Range	50000-59999

Protocol name	AV UDP in
Protocol type	UDP
Direction	Receive/Send
Port Range	3478, 50000-59999

Testing Access – If you are using internal clients to perform multiparty A/V testing then ensure those clients have unrestricted access through your internal firewall. I experienced an issue where outbound traffic from my test clients was being blocked by my internal firewall, which in turn created additional issues. Ensure you have complete outbound access for your test clients and then scale back access from there.

I hope this assists your external A/V conferencing implementation.

OCS 2007 R2 – Public IM Provisioning

September 4, 2010 Leave a Comment

I recently had to assist a customer with public IM provisioning for OCS 2007 R2, and while there are some relatively good guides on how to perform this on the internet, I haven’t found any that actually show you the provisioning form itself. Here are the steps to take in order to provision your SIP Domain(s) for public instant messaging connectivity.

1. Navigate to the Microsoft PIC provisioning website at the following URL: https://ocspic.livemeeting.com/ and sign in with your Windows Live ID.

2. Once logged in with your Windows Live ID you will be presented with the following screen:

On this screen you will need to select your organisations Microsoft Licensing Agreement type, and hopefully you have already purchased the public IM CAL’s you need to federate with Yahoo!, MSN and AOL. Select the appropriate agreement radio button for your organisation, check to agree to the terms of service and you will then be asked for your Microsoft Agreement Number. If you do not supply this number, you will be unable to proceed with the provisioning process.

3. On entering your agreement number you will also see a small area of information that will be required later on in the provisioning process as shown below:

In our case, we need to pay particular attention to the information listed under the “Initiation of new service” section. Once you agreement number is entered click Submit, and you will then be asked for your contact details. Please ensure these are correct, as Microsoft uses these details to send you information on the status of the provisioning process. Once you have filled in your contact details click Next.

4. Select the “Initiation of new service” link and you should then find yourself at the most important screen of the process, this is the area where you specify the FDQN of your Access Edge server and the SIP Domain names you wish to utilise. It is very important both of these values are correct, if the FQDN you specify in the provisioning form is different to that of the subject name specified in your public SSL certificate for your Access Edge service, federation with public IM providers will fail. Likewise this will also occur if you specify the wrong SIP domain names.

For example, if my Access Edge SSL certificate had been generated with the subject name of sip.mycompany.com, the FQDN I would enter in the form would be sip.mycompany.com. In turn, my SIP domain would then be mycompany.com, this is assuming you had configured this external domain name as an additional SIP domain on your Front-End and Consolidated Edge servers.

5. Once you have completed all the required information, click Next and your all done. The lead time on completing public IM provisioning is 30 days, as Microsoft will need to submit this information to both AOL and Yahoo! if you have chosen to federate with the providers as well.

More information on the prerequisites for public IM and completing the provisioning process can be found at the following URL: http://go.microsoft.com/fwlink/?LinkId=155970