Pages

Thursday, September 9, 2010

Configuring Forefront Unified Access Gateway (UAG)

As noted in my previous install post (http://terenceluk.blogspot.com/2010/09/what-installing-forefront-unified.html), the following is the configuration process I went through during the deployment of UAG for DirectAccess:

Once I rebooted the server after the install, I went ahead and ran Forefront UAG Management from the start menu:

image

Had to wait a few seconds before the management console actually launched:

image

The console launches and I was greeted by a friendly wizard:

image

image

Prior to installing UAG, it was important to assign the proper NICs with the external and internal IPs. The following screen is where we identify which was which:

image

image

Here we define what our internal network IP address range is:

image

Easy enough!

image

Next we define the topology:

image

image

I’m actually going to add this server to an array but because I needed to use this install to test an issue we had, I went ahead to configure it as a stand alone topology for now.

image

Again, easy enough.

image

Self explanatory.

image

I chose No for the last option.

image

Once done with the initial network and topology configuration, I was presented with an easy to follow steps:

  1. Clients
  2. DirectAccess Server
  3. Infrastructure Servers
  4. Application Servers

image

Select the security groups of clients computers for UAG direct access:

image

image

image

Notice how the configured nodes have “edit” instead of “configure”.

image

Continue defining the networks:

image

Define the type of UAG DirectAccess required:

image

Define the certificate you’re using where the top is either the root or intermediate certificate you want to verify certificates sent to DirectAccess clients and the bottom being the actual certificate you purchased for authenticating the DirectAccess server to a client connecting:

image

image

Make sure you install the certificate or it won’t show up in the above screen:

image

Here’s a screenshot of what window you’re presented with when you choose the root or intermediate certificate as noted above:

image

Once completed, click finish:

image

Notice the change in the nodes again:

image

Once you click on infrastructure servers, you’ll be ask to enter a location server which you will need to setup prior to the configuration:

image

To validate whether you installed the location server properly, click the validate button:

image

I wont’ go into the settings in the following window as the details can be found on the deployment guide:

image

The wizard picks up the domain controllers but you’ll need to specify the other servers in the environment:

image

image

image

Notice another change in the nodes:

image

We don’t have any Applications Servers ready to be configured yet so I left this as the default:

image

Finally completed all the configuration nodes:

image

Once completed, clicking on the Generate Policies button will present you with the following window where you can click on Apply Now to complete the configuration and this is where it gets interesting for the deployment.

image

image

Once you click on the Apply Now button, you’ll see this window pop up:

image

Yikes!

image

> Executing policy script.

Unexpected token 'The' in expression or statement.

At C:\Users\tluk\AppData\Local\Temp\tmpFE62.tmp.ps1:13 char:80

+ if (-not ${UAGDA_CERT_MACHINE_AUTH}) { ${UAGDA_CERT_MACHINE_AUTH}="C=US, O="T

he <<<< Go Daddy Group, Inc.", OU=Go Daddy Class 2 Certification Authority" }

+ CategoryInfo : ParserError: (The:String) [], ParseException

+ FullyQualifiedErrorId : UnexpectedToken

The install and configuration was easy enough but this error got me stumped for 3 hours of troubleshooting before I was able to resolve it.

The next post will show the troubleshooting steps I went through leading to the resolution.

What installing Forefront Unified Access Gateway (UAG) looks like

While this post isn’t anything special, I had to document an install I did for UAG so I thought I might as well make good use of the documentation and post here in case anyone is interested in seeing the flow of the install and what the wizard looks like.

My next post will include the configuring process and then another post about a problem I had with a third party certificate when I tried to finalize the configuration.

Server Operating System: Windows Server 2008 R2 64-Bit

Patches: Up till September 09, 2010

image

image

image

image

image

image

The nice thing about the installer is that it will install the roles required for the server unlike the earlier products such as Exchange and SharePoint that requires you to manually install the roles and features.

image

image

Pretty straight forward install.

Tuesday, September 7, 2010

Where does Unified Messaging pull the mailbox extension?

I’m sure a lot of Exchange UM professionals out there already know this but in case the person reading this doesn’t:

Ever wonder where Exchange 2007 pulls the Extension Configuration value when you’re enabling someone for Exchange Unified Messaging? The screen I’m referring to is this:

image

New Exchange UM admins may notice that sometimes this field is either:

  1. Populated with the correct value.
  2. Populated with the incorrect value.
  3. Does not have a value at all.

I remember one of my colleagues telling me once that this was actually pulled from the line URI field within OCS but that’s actually incorrect:

image

The place this information is pulled from is actually in the user object’s Telephone number field in Active Directory Users and Computers.

image

I intentionally used this example to show what happens when you populate the Telephone number field with a number formatted in such a way: xxx-xxx-2999 x2910. In this case, Exchange UM just assumed the extension was 2999.

Friday, September 3, 2010

Cisco UCSM Error: “Failure re-acknowledging Slot #. Cause: Slot identity is being established. Try again later".”

I wouldn’t say this was extremely interesting but wanted to write a short post to remind myself what was done in case I run into this again in the future.

A client had ordered 2 x 5108 chassis, 2 x 6120XP fabric interconnects and 8 B-Class blade servers but due to the available of the hardware, Cisco shipped all of the hardware except for the second 5108 chassis. Since the client needed the hardware up as soon as possible, we went ahead and set up the redundant fabric interconnects connecting it to 1 chassis then put all 8 blades into the chassis.

So once the last chassis arrived, we went ahead to move 4 blades from the first chassis to the second one. We got the usual message within UCS Manager:

This slot contains a server that is provisioned for a different slot.

Click here to accept this server in this slot.

image

No surprise here so we proceeded choose Yes when asked:

Are you sure you want to re-acknowledge this slot?

This operation will trigger a discovery of the server in this slot.

image

We continued to repeat this action for the rest of the servers but then ran into a problem with the last blade where we would get:

Failure re-acknowledging Slot 1. Cause: Slot identity is being established. Try again later.

image

Knowing that UCS tends to do a lot of checks when new hardware is detected, I gave it another 10 minutes but when I got back after 15 to 20 minutes to try and acknowledge the change in the blade’s slot, I would still get this message.

What I ended up doing was right click on the Chassis node and chose Re-acknowledge chassis to get past this error message. Strange behavior but since there were other items that needed to be done, I never looked further into it.

I will update this post if I get more time to do some further investigation.