office communications server

Communicator Mobile Update

An update has been released for COMO. If you are one of the lucky people out there running windows mobile, update now.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=93062936-f216-4d97-aa13-105a20454322

Issues that this hotfix package fixes
  • Provides home screen support for new home screens in Windows Mobile 6.5+ phones.
  • Provides integration within the phone dialer for Windows Mobile 6.5+ phones.
  • Enables Communicator Mobile 2007 R2 to recognize when the phone is roaming and by default prevents Communicator Mobile 2007 R2 from signing in to roaming networks.
  • Provides additional support for joining conference calls from a Windows Mobile appointment. To do this, press Menu, and then press Join Conference.
  • Lets users log on by using a user name in the user@example.com format, in addition to the domainuser format.
  • Enables the functionality by which callbacks are now automatically accepted when the user uses the Call via Work option.
  • Resolves the problem in which the Microsoft Installer (.msi) installation fails on a Windows XP Service Pack 3 (SP3)-based computer. In this situation, users should install Communicator Mobile 2007 R2 by using a (.cab) installation.
  • Fixes the problem in which AT&T FUZE devices that are set for a High-Speed Downlink Packet Access (HSDPA) connection cannot handle voice and data at the same time. In this situation, calls that use the Call via Work option fail unless the device is reverted to 3rd Generation (3G) by disabling HSDPA.
Posted on by Randy Wintle in COMO, OCS, OCS 2007 R2, Unified Communications Leave a comment

Configuring and Using Call Park In Communications Server 2010 (Beta)

One of the new enhanced telephony features supported in Communications Server 2010 is Call Park.

This feature allows you to “park” a call, and allow another user to pick up this call from the assigned extension. This was a common scenario on traditional PBX systems. Think of  “Randy, you have a call on 12345”. I can go to any phone, dial 12345, and answer the call on hold for me.

This feature requires you to dedicate a block of numbers in your environment for call park. This set of numbers can also start with a * or  #.  You must also be using Communicator 2010 to retrieve a parked call. Below, I will outline how to create a basic call park number range, and how to use this feature in the communicator client.

Note: These commands and screenshots are from the Beta release of Communications Server, appearance of commands may change at release

Creating the Call park Number Range

You can create or modify call park ranges in powershell or in The communications Server Control Panel, the new silver light based control panel for Communications Server.

Powershell

First, make sure you are on a machine or server with the CS 2010 Admin Tools Installed, Open the  Communications Server Management Shell

image

For the Beta, the set of commands related to the Call Park service are:

Get-CsCallParkOrbit
New-CsCallParkOrbit
Remove-CsCallParkOrbit
Set-CsCallparkOrbit
Set-CsCallParkServiceMusicOnHold

As you can see below, in my environment when I run a Get-CsCallParkOrbit I have a number range configured as park test already in my beta deployment:

image

The call park number ranges have very basic information associated with them, The identity, and a set of number ranges and a server.

Lets create a new call park range with the name Winxnet Parking Lot and the number range #900-#950

This configuration would allow for me to have 50 Parked calls based on that range.

The command we are concerned with here is New-CsCallParkOrbit

Below is the cmdlet help information on this command:

NAME
    New-CsCallParkOrbit

SYNOPSIS
    Creates a new, named, range of extensions assigned for parking calls within
     an organization.

 

SYNTAX
    New-CsCallParkOrbit -Identity <XdsGlobalRelativeIdentity> -NumberRangeStart
     <String> -NumberRangeEnd <String> -CallParkService <String> [-Confirm [<Sw
    itchParameter>]] [-InMemory <SwitchParameter>] [-Priority <Int32>] [-Tenant
     <Nullable>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

DESCRIPTION
    Parking a call assigns a received phone call to a specific extension for la
    ter retrieval. A call park orbit is the set of extensions defined to a spec
    ific call park server for this purpose. The New-CsCallParkOrbit cmdlet defi
    nes the extensions for a call park orbit and applies them to a specific a s
    ervice. Calls parked within the given range will be parked on the specified
     Call Park Service. Multiple call park orbits can be created; each must hav
    e a globally unique name and a unique set of extensions.

 

For my example, this command will read:

New-CsCallParkOrbit –Identity “Winxnet Parking Lot” –NumberRangeStart “#900” –NumberRangeEnd “#950” –CallparkService winx-cs2010b3.winxnet.com

Note the number range being in quotes because I am using a # symbol.

The output should look like below:

image


Communications Server Control Panel

The Communications Server Control Panel is the replacement for the old MMC snapin with previous OCS Versions. This is a silverlight based web client to manage majority of Communications Server Settings.

To complete the above configuration in the UI, first open Internet Explorer and navigate to your CSCP web page:

image

This UI may be changing a bit, so I will just cover what is involved in creating a call park group.

In the left navigation menu, choose Voice Features

image

You will see in the screenshot above the Call Park Number Range I previously created using powershell.

To create a New range Select New

image

You will be presented with a form to enter the same information as above. The only difference is that “Destination” is the CallparkService from your power shell command.

User Experience


Now that you have created a Call Park Number Range in your communications server environment, your clients should be able to place calls on park hold, and retrieve these calls.

While in a call, under the Transfer menu, you will have a new Option for Parking Lot

parkinglot2

When you choose Parking Lot it will park the call, and notify you the call has been parked, and what number to dial to retrieve. You also have the option to Copy the text. If you copy the text it can be pasted into an IM or an Email to send to another user.

image

Now, in communicator I can dial the number specified in the message, to retrieve the call.

image

Once the call has been retrieved, the user will be notified that the call was retrieved, and the person retrieving the call will be connected to the user on the line.

parkinglotanswered

The left side of the screenshot is the notice that the call was answered, and the right side is what it looked like when I retrieved the call.

This is one of the many great new functionalities coming with Communications Server 2010 later this year, to find out more please visit: http://www.microsoft.com/uc/

To learn more about CS 2010 Powershell, check out this awesome blog http://blogs.technet.com/b/csps/

Posted on by Randy Wintle in Communications Server 2010, Enterprise Voice, Unified Communications 2 Comments

Issue with DTMF While in Conference Call

I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsconferencing/thread/f9512694-c298-4951-b6d6-0d240ccd0397

 

The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:

  1. Communicator call, or communicator conference call is initiated
  2. User invites a PSTN number to that conference call
  3. PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
  4. No DTMF is received by the PSTN number.

So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.

I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.

Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.

Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.

 

Thanks!!

EDIT:

That was quick! http://support.microsoft.com/default.aspx?scid=kb;en-us;2254369&amp;sd=rss&amp;spid=12605

It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!

Posted on by Randy Wintle in Audio/Video MCU, Communications Server 2010, Conferencing, Dialogic, Enterprise Voice, OCS 2007 R2, Unified Communications 7 Comments

Issue with DTMF While in Conference Call

I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsconferencing/thread/f9512694-c298-4951-b6d6-0d240ccd0397

 

The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:

  1. Communicator call, or communicator conference call is initiated
  2. User invites a PSTN number to that conference call
  3. PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
  4. No DTMF is received by the PSTN number.

So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.

I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.

Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.

Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.

 

Thanks!!

EDIT:

That was quick! http://support.microsoft.com/default.aspx?scid=kb;en-us;2254369&amp;sd=rss&amp;spid=12605

It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!

Posted on by Randy Wintle in Audio/Video MCU, Communications Server 2010, Conferencing, Dialogic, Enterprise Voice, OCS 2007 R2, Unified Communications 13 Comments

Configuring Warning Message in CS 2010

In OCS 2007 you could configure warning messages through group policy, along with a ton of other settings, reference to which can be found here:

http://download.microsoft.com/download/e/a/d/eadae6db-d136-4f05-b46f-98188361238b/Communicator_2007_Group_Policy_Settings.xls

In CS 2010 these settings can still be applied through existing Group Policy Objects, however CS has introduced Client Policies to replace these group policy settings. These client policies come down through in-band provisioning to the communicator client.

The example I will show here is one of the most common, and that is the IM Warning.

First, login to your CS 2010 server, and open the Communications Server Management Shell

To see your client policies, and the settings associated with them type the following and hit Enter:

Get-CSClientPolicy



As you can see, there are a lot of familiar settings available in these client policies.

As you can see, the policy in my Beta deployment is just the Global Policy. These policies can be configured, and then applied on a per user basis, with the default Global Policy getting applied to users if no other policy is specified.

Now on to the example here, configuring the IM Warning.

The Powershell command to set this is:

Set-CSClientPolicy -Identity Policyname -IMWarning “IM Warning Text Here”

If you only have one policy, you do not need to specify an identity, it will default to your Global policy.

To see a full description of the Set-CsClientPolicy and New-CSClientPolicy commands in Powershell simply type:

Get-Help Set-CsClientPolicy or Get-Help New-CSClientPolicy

In my ennvironment I will be entering in:

Set-CsClientPolicy -IMWarning “Communications Server 2010 Rocks!!”

To confirm the settings have applied correctly, type Get-CsClientPolicy and hit enter.

To apply these settings to your communicator client, exit the client and restart the client.

Now, open an IM Window to confirm the warning message is displayed:

As you can see, the future of CS management is in powershell, for even the smallest things like the IM Warning.

I will cover in more detail Client Policies and Voice/Conferencing policies soon on this Blog, but this should be a good introduction to what you can do with CS Client Policies and Powershell.

Posted on by Randy Wintle in Communications Server 2010, Unified Communications 5 Comments

Reference: Setting Event Log Levels for Exchange UM

Exchange 2007 and Exchange 2010 allow you to configure different event logging levels for all Exchange services.

I commonly have to enable more detailed Exchange UM logging on UM servers to troubleshoot call flow issues, so here is a quick reference of how to do this.

First off, here is the technet reference to doing this for all services:

http://technet.microsoft.com/en-us/library/bb201670(EXCHG.80).aspx

In Exchange 2007, you must do this through Powershell, Exchange 2010 however is available right in the Exchange MMC.

For Exchange 2007:

Start by opening your Exchange Management Shell

The following powershell commands are required for the Exchange UM services

set-eventloglevel -identity “MSExchange Unified MessagingUMWorkerProcess” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMCore” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMManagement” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMService” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMClientAccess” -level Expert
set-eventloglevel -identity “MSExchange Unified MessagingUMCallData” -level Expert

In Exchange 2010 the same powershell commands will work, however, if you are more comfortable with the UI, you can do it directly in the Exchange MMC.
First open the Exchange Management Console
Expand your On-Premise Organization and select Server Configuration

Select your UM server from the list of available servers, and you will notice on the right hand side, under Actions for that server you will have Manage Diagnostic Logging Properties


Select Manage Diagnostic Logging Properties and you will be prompted with a full list of services on your Exchange server to manage. Expand MSExchange Unified Messaging, for each service you wish to raise the level, select that service, and then select the option for whatever level you wish to enable. Expert is typically a good level to have if dealing with UM.
Once you have configured all of your service levels, choose configure. This will basically execute the Powershell commands listed above and confirm Completion.
Posted on by Randy Wintle in Exchange 2007, Exchange UM, Microsoft, Unified Communications 1 Comment

Quick Tip: Exchange UM Powershell to list users in a specific dial plan

This is a basic one liner I needed to use today, but I didn’t find it documented that well anywhere.

Situation: Multiple exchange UM dial plans in a company, need to identify users associated with a certain dial plan for whatever reason. In this case it was to migrate them off that dial plan.

Going through the UI to do this would be way too time consuming, of course powershell comes to the rescue.

Using the Get-UMMailbox cmdlet with a basic filter we can identify a group of users with many different attributes in common, in this case we are concerned with UMDialPlan.

Command looks like this:

Get-UMMailbox | where {$_UMDialPlan –eq ‘DialPlanName’}

This will return a list of users in the dial plan you specify. You could of course add more filters in to narrow down the scope.

Posted on by Randy Wintle in Exchange 2007, Exchange UM, Unified Communications 1 Comment

Communications Server 2010 Features Made Public

Communications Server “14” or 2010 had all of its features finally announced and made public today at TechEd. Hopefully soon I will have some blog posts out on the new functionality and new configurations!

http://www.microsoft.com/communicationsserver/CS14/en/us/new-features.aspx

Posted on by Randy Wintle in Communications Server 2010, Unified Communications Leave a comment

Publishing Communicator Web Access (CWA) with Forefront Threat Management Gateway 2010

In my previous post I outlined configuring Forefront TMG 2010 to publish the OCS 2007 R2 web components. Please see that post for basic installation instructions and network configurations.

In this post, I will outline publishing Communicator Web Access (CWA) to the internet using Forefront TMG 2010.

DNS Records and Certificate Requirements

First lets cover the new DNS records and certificate entries required for communicator web access. With the addition of desktop sharing to CWA, additional DNS records and certificate entries are required to provide that functionality.

The following DNS records are required for CWA:

DNS Record

Usage

Record Type

cwa.domain.com

CWA Access

A record

as.cwa.domain.com

CWA Desktop Sharing

CNAME to cwa.domain.com

download.cwa.domain.com

CWA Desktop Sharing

CNAME to cwa.domain.com

Your certificate will need to have all of the names above on it.

In my environment I have the following certificate information:

Common Name: cwa.winxnet.com

Subject Alt Name(s): as.cwa.winxnet.com download.cwa.winxnet.com

CWA Web Site Configuration

In my example I have two web sites configured on the CWA server. One for internal access and one for external access. When you create virtual servers for CWA you have two options for site types, Internal and External. The only difference is authentication type. Internal sites will let you choose NTLM authentication, which allows for simple access from inside the corporate network on domain joined machines. External sites will use Forms-Based Authentication, or Custom Authentication. Custom authentication can be used to perform two factor authentication with services like RSA or other smart card/pin authentication methods.

In our example our Internal site will be a standard internal site listening on port 443. Our external site however will run on port 4443, and we will perform bridging with the forefront TMG server to give users access to this site.

I will outline creating the external web server, assuming an internal web server has been configured listening on port 443.

First, open the Communicator Web Access management console, this is separate from the OCS 2007 R2 primary admin console, but is included when you install the admin tools on any machine.

Right click on the server name and choose Create Virtual Web Server.

image The first splash screen just gives basic information about requirements for this task, just hit Next.

image

At the next window, this is where you will choose your web server type, choose External.

image

The next window allows you to choose your authentication types. If you were using a third party authentication method you would specify it here. Although it says in the description that the built in windows integrated and forms-based authentication will be used, the external web site will only allow Forms-Based Authentication.

image

The next window confirms those authentication settings, notice NTML is grayed out.

image

The next screen has you specify an SSL certificate to be used with the https requests. You can choose HTTP if you are using an SSL Accelerator device, but you cannot use CWA over HTTP without such a device.

Choose the certificate you created with all the necessary name entries and hit Next

image

The next screen has you specify the IP address and port the web site will listen on. If you have an additional IP address you can use port 443 with a separate IP than your internal server. In our example, I will be using a single IP address and utilizing bridging with Forefront TMG, so I will enter the port as 4443.

image

On the next screen, enter a name to identify the external web site such as CWA External.

image

The next screen has you specify a port to listen to OCS traffic. This is seperate from the web site listening settings. This port is really important if you are collocating OCS Services, or even in this case where we have multiple CWA virtual servers on the same server. This port really does not matter, as long as it does not conflict with another port on the same server used for OCS Traffic. In my case I am entering 5071, my internal server listens on 5070.

image

At the next screen you must specify a Next Hop Pool, this drop down will display all the pools in your environment and allow you to choose a pool and listening port. In my case our poolname is ocs.winxnet.com.

image

Hit Next twice to confirm your settings for the new virtual server, the wizard will create the virtual directory and start the web site for you. As with all of the OCS installations, a log is available at the end for success and failure.

image

Now review your two sites, a screenshot of how the site summary should display is below.

imageTest access to your web site on the port you specified during setup, and you should see a form to login because we chose External for the site type.

image

Now that the OCS configuration is complete, we will configure Forefront TMG Web Site Publishing rules to allow traffic to your CWA services.

Forefront TMG 2010 Configuration

My last post reviewed networking configurations for this Forefront server. You can get away with a single External/DMZ IP address for all of these services if you have a single certificate with all of the names. In my case I have multiple certificates, so another IP address will need to be assigned to the DMZ network card on my Forefront TMG 2010 server.

Once you have added your external IP address, and imported the certificate used on your web server; (See my last post for instructions on both of these steps). We will now create the web site publishing rule for CWA.

Right click on Firewall Policy and choose New->Web Site Publishing Rule.

imageOn the New Web Publishing Rule Wizard first page, enter a name for your rule like CWA. Hit Next.

image 

For a rule action, choose Allow. Hit Next

image

For the Publishing Type choose Publish a single web site or load balancer. Hit Next.

image

For Server Connection Security choose Use SSL to connect to the published Web server or server farm. Hit next.

image

For your internal site name, you will want to specify the same Internal/External site name, whatever is the common name on your certificate, in my case it is cwa.winxnet.com.

image

If you cannot resolve the name correctly from the TMG server, or want to specify a different computer to connect to for that name, you can do so by specifying a computer name or IP Address.

image

Once you have made the necessary entries, hit Next.

For internal publishing details, under path type /* to allow all sub directories required by CWA. Hit Next.

image

Under Public Name Details enter the public name for your site, and hit Next. In my case it is cwa.winxnet.com.

image

On the next page to specify a web listener, choose New.

image

In the new web listener wizard first page, enter a name for the listener like CWA.

image

For Client Connection Security choose Require SSL secured connections with clients.

image

On the Web Listener IP Address page, select the check box next to External, highlight external and choose Select IP Addresses… On this next page, specify the IP address you set aside for CWA.

image

Hit Next, on the next page for Listener SSL Certificates, highlight the IP Address selected on the last page and choose Select Certificate… Choose your valid certificate and choose Select. Hit Next.

image

image

For Authentication settings, choose No Authentication.

image

Because we chose No Authentication, we have no SSO options, just choose Next.

image

Review the settings for your listener and hit Finish.

image

With your listener selected from the drop down menu, hit Next.

image

For Authentication Delegation choose No Delegation, but client may authenticate directly. Hit Next.

image

Leave the default settings for User Sets and hit Next.

image

On the next page, select Test Rule to verify all rule settings are correct. If the result is OK, hit close, then select Finish.

Make sure to Apply your settings to the Forefront TMG server before continuing.

image

If you had a separate IP address for you internal site, and your external site you do not need to do the next step. This next step will configure bridging to direct our user request to port 4443 for this external virtual server.

Right click on your CWA rule and choose Properties.

image

On the Properties page, select the Bridging tab.

image

Where it says Redirect requests to SSL port, enter port 4443, or whatever port you specified during your website configuration. Hit OK.

Again, apply your changes before continuing.

image

You can test the rule again from the Properties page. Simply open the Properties page for the rule and Test Rule will be an option there. If the test returns OK, continue to test your site from a computer outside the network.

Testing and Known Issues

You can test access to this site from Internet Explorer outside the network, you should simply be able to specify the https:// URL of your site, and TMG 2010 will handle bridging the request to the correct virtual server on the CWA server. You can also use CWA for access to a great IPhone OCS App called iDialog by Modality Systems.

A very common known issue for CWA configurations is receiving the error Cannot sign in because your computer clock is not set correctly or your account is invalid.  (Error Code: 0-1-492)

This is an easy fix, and has to do with Service Principal Name (SPN) settings for the CWA Site.

To fix this issue, simply add the correct SPN to your CWA Service Account. This is the account specified during CWA installation to run the service.

You can modify this setting using ADSI Edit, and looking for the attribute servicePrincipalName.

imageEnter the SPN for your site in the form http/cwa.winxnet.com where cwa.winxnet.com is your internal or external FQDN of the site.

I also blogged before about my experiences when load balancing CWA.

Other than those two instances, this configuration is pretty straight forward and just works.

Posted on by Randy Wintle in CWA, Forefront TMG 2010, Load Balancing, OCS, OCS 2007 R2, Server 2008 R2, Unified Communications 11 Comments

Configuring Forefront Threat Management Gateway for OCS 2007 R2 Part 1

The reverse proxy installation can be confusing if you have never done it before. In this scenario I will be standing up a new server to replace my ISA 2006 SP1 Server. I will create all of the rules from scratch and walk through the installation.

Network Configurations

The most important part of this reverse proxy setup is the networking configuration. It is recommended to have at least two network interfaces on the TMG server, in my case we have a network card in the DMZ with public IP addresses and one on the internal network. Depending on your actual network configuration this could be different.

An important thing to note is that in windows you can have multiple network interfaces on different networks, but not multiple default gateways. Because of this, we need to choose an adapter with the default gateway, and one without any gateway, using manual routes to get to internal resources. In most scenarios it would be ideal to assign the default gateway to your internet facing NIC, this is because it is impossible to enter manual routes for all possible internet traffic. The internal or DMZ NIC typically has no gateway, but we will assign persistent routes for the internal networks.

In my case, the NIC is directly on the internal network, so servers can communicate directly on the same subnet with no routing needed. However, I will show you how to configure these routes for another internal network to simulate the need to route. In an edge server configuration you will need routes for the desktops as well as servers, so it is important to know how to do it.

In my situation, the address spaces involved will be as follows:

Server LAN: 10.117.117.0

Desktop LAN: 10.1.2.0

DMZ: Public IP addresses

Because my TMG server has a NIC directly on the 10.117.117.0 network I do not need a route for that network, but in order to talk to the 10.1.2.0 network, I will need persistent routes. To see the route setup on your server:

Open a command prompt as administrator

Type Route Print and hit enter

image

Your output should resemble something like the picture above. Note the 10.117.117.0 network has routes directly on that link, and the default gateway is set to our public interface.

To add a route to the 10.1.2.0 network type the following at the command prompt and hit enter:

route add –p 10.1.2.0 MASK 255.255.255.0 10.117.117.2

Where 10.117.117.2 is the router on your network.

If you see OK! after you hit enter, the command took succesfully.

image

This means any requests for that network are in the route table, and are to go to 10.117.117.2, which will happen via the 10.117.117.106 interface, or our Internal interface.

This is a fairly basic network configuration, in most environments it will be more complex and involve more subnets. However hopefully this gives you a good idea of how to setup the network in your environments.

TMG Installation

Before I get started, the diagram below will show the basic environment as it relates to the reverse proxy and my OCS Pool.

OCSRP

Update the server with the latest patch levels, and then launch the TMG Install. You will get a screen prompting you to Perform Updates, Run the Preparation Tool, or Run Installation Wizard.

image

Select Run Preparation Wizard. This Wizard will add the server role required for TMG to operate on the server. As you click through the installer you will have to choose a type of installation, choose Forefront TMG services and management for a complete install.

image

Let the wizard run, it will install all roles and services needed. When completed you will be presented with a screen that shows Success or Failure, Click Finish and Launch the TMG Installation Wizard.

image

The installation wizard will have a few defaults to accept, and then you will be asked to choose your internal network ranges. Choose Add, then choose Add Adapter. Select the Internal network interface on the server. If you previously entered persistent routes you will notice those subnets show up as being associated with that adapter as well.

image

Hit OK twice and your window should look something like this:

image

The address ranges should reflect your DMZ adapter address and any internal networks you will be routing to.

Hit Next twice to acknowledge the services that will be restarted during the install. The next page will notify you that forefront will create rules to allow domain traffic to domain controllers listed

image

If this information looks correct, hit Next, then Install and let the installation complete.

image

The installation will take some time to complete, but once it is done you should see this screen, click Finish to launch the configuration wizard.

image The initial configuration wizard will then launch. Note: You can import ISA 2006 XML configuration files to this if you do not wish to recreate your rules. I am going to start from scratch however to show the whole configuration process.

image

Run the wizard to configure network settings. This setup is an Edge Firewall configuration. Choose Edge and click next.

image

Choose your internal network adapter to be associated with the LAN. You may also enter routes here, I am not sure if this makes the previous routes entered not needed, but I will do more testing and update the blog if that changes.

imageThen choose your external adapter, in my case labeled DMZ

imageConfirm the information, and choose Finish.

imageJust to continue through the wizards, although not necessary needed, you can choose Configure System Settings which basically has you confirm the computer and domain settings.

imageimage

The next step is to define Deployment Options which chooses your license information, and update settings. I will not cover that in this post.

image

Once you launch the TMG Console, you will notice a somewhat familiar interface with a whole lot of new features.

image

OCS Website Publishing Rules

Before starting with any OCS rules you should import the public certificates for your OCS Web Farm.

You should have a standard SSL certificate with a common name that matches the External Web Farm FQDN you specified during setup, or that name should reside on a UCC certificate. Either way, you must import that certificate into the Local Computer store with a valid Private Key before it can be used with ISA.

To do so, open the certificates MMC.

Right click on the Personal certificates store and choose All Tasks –> Import

imageIn the certificate import wizard, select the certificate file for your web farm certificate.

imageHit Next, enter the password used when exporting the certificate private key.

imageHit Next, choose to place the certificates in the following store, Personal should be selected.

image

Hit Next, then Finish. Your certificate should now be ready for use with ISA. 

For OCS, we are simply concerned with Firewall Policies, there are a lot more features to TMG 2010, which I hope to cover at a later date.

Select Firewall Policies, and choose Publish Web Sites from the tasks pane on the right

imageEnter a name for the rule such as OCS Web Components

imageHit Next, for a rule action choose Allow.

imageHit Next, choose Publish a single website or load balancer.image    Hit Next, choose Use SSL to connect to the published web server or server farm.

imageHit Next, for the internal site name enter your internal web farm FQDN, usually the pool name. If the ISA server cannot resolve that pool record, you can specify a computer or IP address as well.

image 

Hit Next, for the path enter /* to allow all traffic to the pool for the various services.

imageHit Next, for the public name, enter your external web farm FQDN. You should have set this during install, or manually configured later.

image  Hit Next, choose New to create a new web listener. Enter a name for the listener such as OCS Web Listener.

imageHit Next, choose require SSL secured connections with clients.

imageHit Next, for the web listener IP address choose the External Network, hit Select IP Addresses.

Choose the radio for Specified IP Addresses on the forefront TMG Computer in the selected network. 

Select the IP address that will your web farm FQDN dns A record points to, and choose Add so it shows in the selected IP addresses column.

imageHit Ok, then Next. For the Listener SSL Certificates make sure Assign a Certificate for Each IP Address is selected.

Highlight the IP address and choose Select Certificate…

The next page will show you the valid certificates installed to the local computer personal store on your server. Choose the certificate for your OCS web Components and choose select.

imageHit Next, for authentication settings choose No Authentication from the drop down menu.

image

Hit Next twice, choose Finish to complete the listener configuration, you will be brought back to the web site publishing wizard with the new listener selected.

Hit Next, for authentication delegation choose No Delegation, but client may authenticate directly.

imageHit Next twice accepting the defaults, and choose Finish to create the rule.

Make sure you hit Apply to actually commit the rule.

imageOnce the rule is created, TMG 2010 has built in tools to test that rule for you. Right click on the rule and choose Properties. Then select Test Rule.

imageIf everything is working, including certificates, and authentication access, you will see all green. Any errors will have descriptions of the problem and how to fix it.

image   A new feature of TMG 2010 is a path ping, that basically is a traceroute of the path taken to get there. Use this to verify your routing configuration from before.

image 

Now that this rule has been configured and you have an external DNS A record pointing to your External Web Farm FQDN, your users should be able to access the OCS web components remotely.

In the next post I will outline configuring TMG 2010 for Communicator Web Access.

Posted on by Randy Wintle in Forefront TMG 2010, Networking, OCS 2007 R2, Server 2008 R2, Unified Communications 9 Comments