RSS Subscription 168 Posts and 2,769 Comments

Archive for June, 2008

Office Communications Server 2007 Enterprise Deployment – Part 2

Welcome to Part 2 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is how to deploy a single Enterprise Edition OCS Server which is connected to an x64 SQL Server 2005 SP2 Back-End Server. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of our Enterprise Certificate Authority.

In this Part, I will go over the preparation and installation of a Front End OCS 2007 Server Pool.

Part 1

Part 2

Part 3

Part 4

Part 5

Front End OCS 2007 Server Installation

When installing OCS in a consolidated Enterprise Edition deployment, you would perform the following steps:

  1. Prepare Active Directory
  2. Create an Enterprise Pool
  3. Configure a Load Balancer
  4. Configure Pool / DNS
  5. Add Server to Pool
  6. Configure Certificate
  7. Configure Web Components Server Certificate
  8. Verify Replication
  9. Start Services
  10. Validate Server and Pool Functionality

Note: We will not be able to go over all the steps in this Part 2 due to the amount of steps and sub-steps required to perform.

Prepare Active Directory (Step 1)

Our Domain Controller with Windows Server 2003 SP2 is installed and fully functional.  To begin the Active Directory preparation process, we can insert our OCS CD.  There are some prerequisites for installing OCS such as .Net Framework 2.0, but this is all taken care of during the installation.

Insert the CD and let’s begin the installation process.  You will be asked to install the Microsoft Visual C++ 2005 SP1 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 2.0. Click Yes to Continue.

Once Microsoft .NET Framework 2.0 is installed, you will be presented with the Deployment Wizard.  We will want to deploy our Enterprise Pool in a Consolidated Topology.  Click Deploy Pools in a Consolidated Topology to Continue.

We are now on Step 1 which is to Prepare Active Directory. Click Prepare Active Directory to Continue.

We are now presented with sub-steps to perform to complete our Active Directory Preparation.  These sub-steps include:

  1. Prepare Schema
  2. Verify Replication of Schema Partition
  3. Prep Forest
  4. Verify Replication of Global Settings and Global Catalog
  5. Prep Current Domain
  6. Verify Replication of the Domain
  7. Delegate Setup and Administration

Click Run for Prepare Schema to Continue.

On the Welcome Screen, Click Next to Continue. Select “Default: Schema files are located in the same directory as Setup.”  Click Next to Continue.

You are now ready to Prepare the Schema.  Click Next to Begin Schema Preparation.

When the Schema Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

We are brought back to the Deployment Wizard.  The Prep Schema step has been complete as is shown next to the Run button.

We will skip through all the Replication Steps (Verify Replication of Schema Partition, Verify Replication of Global Settings and Global Catalog, and Verify Replication of the Domain) due to the fact we have only 1 Domain Controller in this lab.  In a production environment where you have more than one Domain Controller (hopefully), I highly advise you to ensure replication for each step has completed successfully before continuing.

We are now ready to run the Prep Forest step. Click Run for Prep Forest to Continue.

On the Welcome Screen, Click Next to Continue.

You are presented with two options:

  • System Container in the Root Domain
  • Configuration Partition

To decide which option to choose, follow this diagram provided by the Microsoft OCS Team to make a decision.  You can read the blog post which contains this image as well as a lot more information here.

Because this lab contains only one Domain Controller, we will choose the Default setting of System Container in the Root Domain. Click Next to Continue.

We will want to store our Universal Groups in our shudnow.net domain.  In the case of this lab, we will have to due to the fact that this is our only domain.  Select shudnow.net and Click Next to Continue.

We will use our Active Directory domain name shudnow.net for OCS routing.  Click Next to Continue.

You are now ready to Prepare the Forest.  Click Next to Begin Forest Preparation.

When the Forest Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

We are brought back to the Deployment Wizard where we will now run the Prep Current Domain.  This step should be run in any domain that will contain users that will be OCS (SIP) enabled.

Click Run for Prepare Current Domain to Continue.

On the Welcome Screen, Click Next to Continue.

On the next screen that provides Domain Preparation Information, read the excerpt provided and Click Next to Continue.

You are now ready to prepare the domain.  Because we have only 1 domain and are running this step in our shudnow.net domain, our current settings will display as shudnow.net. Click Next to Continue.

When the Domain Preparation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

The final step is to Delegate Setup and Administration.  Because we are doing everything using a Domain/Enterprise/Schema Administrator account, we will not have to configure Delegation.

Creating File Shares

Because our Universal Groups have been created, we can now create file shares that are necessary for the following functions:

  • Presentations – Meeting presentations to be downloaded or streamed by conference attendees.
  • Metadata – Meeting information (metadata) that is used internally by the Web Conferencing Server component for the pool.
  • ABS – Address Book information that is used by the Address Book Server, which is included with the Web Components Server, in order to provide global address list information to Office Communicator 2007 and Office Communicator 2005 clients on a daily basis.
  • MeetingCompliance (optional) – Meeting activities and content uploaded during meetings.  We will talk about how to enable Meeting Compliance in a future Part.

These shares can be created on a File Server in your environment.  We will be creating these shares on our OCS FE Server which means that our OCS Server will also be our Web Components Server.

We will create a folder called C:\OCS on our OCS Server.  Within those four folders, we will create the following four folders:

  • Presentations
  • Metadata
  • ABS
  • MeetingComp

Each of these folders will need to be shared out.  We will use a share name that matches the folder name for simplicity sake.  Grant Full Control on each of these shared folders to the administrator, the RTCUniversalServerAdmins group, and any other user or group responsible for creating pools. Remove Read permission from the Everyone group.

Update: I accidentally left out that you need to add the RTCComponentUniversalServices group to the permissions as well with Full Control.

Update2: The Presentations needs to allow Everyone read permissions in order for people to download uploaded content to Live Meeting.

Make sure you provide both RTCUniversalServerAdmins and Administrators Full Control via NTFS permissions as well.  Because our folders are in the OCS folder, we can add these permissions on C:\OCS and they will flow down to our sub folders through inheritance.

Create and Enterprise Pool (Step 2)

Before we continue on, we need to do some prerequisite work.  This prerequisite work is detailed here.  For purposes of this lab, I would focus on the SQL Server 2005 x64 information since we are using SQL Server 2005 x64.

Because we are running SQL Server 2005 x64, we will need to create our pool on a x86 system.  Because our OCS Front End is x86, we will use our OCS Front End for Pool Creation.  And because we will be doing this from a remote system (our Front End), we will need to install the SQL database management objects (SQL DMO) on our Front End.  This functionality is included in the Microsoft SQL Server 2005 Backward Compatibility Components which you can find here.  Make sure you download the x86 version.  Once that has been installed, you can now proceed.

We are now on Step 2 which is to Create an Enterprise Pool.  This is where you will definitely need to have your SQL Back End fully configured. You can use SQL Server 2005 (x86 or x64) with SP1+.  You can also use SQL Server 2000 SP4+. Click Run to Continue.

On the Welcome Screen, Click Next to Continue.

We must now decide what we want our Pool Name to be.  On an OCS Standard Edition Server, your Pool name is the name of your server.  But since we are using Enterprise Edition, we must select a name that won’t match any other existing records currently housed in DNS.  We will use the name, OCSPool.  Our SQL Server was installed using the Default Instance.  Because of that, all we will need to do is ensure we are logged on with an account that is a member of Domain Admins, RTCUniversalServerAdmins, and has permissions to create and manage SQL Databases. Click Next to Continue.

We will want to leave our Internal web farm FQDN alone.  This should be the pool name.  If you are going to be installing multiple Front End Servers behind a Hardware Load Balancer, the OCS Pool DNS would be pointed to your Hardware Load Balancer Virtual IP Address which would then direct the traffic to one of your Front End Servers.

The External Web Farm FQDN is used by your ISA Server.  It allows you to reverse proxy (publish) your Address Book, Web Conferencing Meeting Content, as well as expansion of Exchange Universal Distribution Groups.  I would recommend configuring this during the install as you cannot modify this through the OCS Administrative GUI.  You can use the guide here to modify the External web farm FQDN should you decide you don’t want to set this FQDN during install or wish to change it at a later time. Click Next to Continue.

Note:  I used the FQDN of ExtWebFarm.shudnow.net.  Taking a look at this from a perspective of a production environment, the shudnow.net name is my AD Domain.  If you do not have split-dns, you can use the same namespace that you will be SIP enabling users.  For example, our SIP Domain is exchange.shudnow.net.  So I can easily just do ExtWebFarm.exchange.shudnow.net.

I am selecting to overwrite any existing database since I did use my SQL Server for a previous OCS installation.

OCS is smart enough to detect whether SQL has any volumes that are now the system volume.  When it does detect these separate volumes, it will try to optimize the locations as much as possible.  Because I do have a separate LUN/volume on my SQL Server, OCS automatically used the E:\ volume to place Database and Log files.  Make any changes here as you wish.  There is a Database Planning guide located here. Click Next to Continue.

The time has now come to specify the location of the shares we created above.  These should be:

  • Presentations – \\OCS-OCS1\Presentations
  • Metadata – \\OCS-OCS1\Metadata
  • ABS – \\OCS-OCS1\ABS
  • MeetingComp – \\OCS-OCS1\MeetingComp

Make sure you test all of the Universal Naming Convention (UNC) paths work prior to proceeding.  If they do work, enter the UNC paths as is displayed in my screenshot. Click Next to Continue.

Configure your the ABS UNC Path. Click Next to Continue.

Since we will not be enabling Archiving or CDR in our environment, leave the Archiving and CDR settings unchecked. Click Next to Continue.

We are finally ready to create our Enterprise Pool!  Review your Current Settings.  When satisfied, Click Next to Continue.

When the Pool Creation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Configure a Load Balancer (Step 3)

If you are going to be doing any type of redundancy, you will need to use a Hardware Load Balancer such as an F5 BIGIP with the LTM Module.

The steps required to configure a Load Balancer is out of the scope of this article as we are deploying a single Front End server which does not require a Hardware Load Balancer.

The hardware load balancing planning information can be found here.

The hardware load balancing deployment information can be found here.

Summary

Well folks, that is all for Part 2 of this article. For Part 3, I will go through the initial configuration of the pool, certificates, and adding our Front End Server to our newly created pool that uses a SIP namespace (exchange.shudnow.net) that is separate than our AD Namespace (shudnow.net). We will begin the steps needed to validate our configuration to make sure the Front End OCS Server is healthy.

Share

Publishing Symantec Enterprise Vault in ISA 2006

I have seen many people encounter issues with publishing Symantec Enterprise Vault behind ISA 2006.  For our scenario, OWA users go through ISA both internally as well as externally.  Why do we do this?  Well, when you are publishing OWA 2007 behind ISA 2006, one of the requirements is to go onto your Exchange 2007 Client Access Server (CAS) and disable Forms Based Authentication and enable Basic Authentication instead. This is because ISA 2006 will be using Forms Based Authentication. Switching OWA on Exchange 2007 to use Basic Authentication instead of Forms Based Authentication allows us to avoid being prompted twice for authentication (once by ISA and then once by Exchange).  Basic Authentication on the CAS allows ISA to pass the authentication through to Exchange without being prompted a second time.

So why do we point both internal and external users through ISA?  That is because we want users to get the same OWA experience both internally and externally.  We don’t want internal users pointed directly to Exchange and get a Basic Authentication prompt while external users get Forms Based Authentication when outside the corporate network.  By pointing internal and external users directly through ISA, they will get the same experience internally and externally.

As you can see in the following image, in Symantec Enterprise Vault, IIS contains several directories which include a directory called EnterpriseVault:

Prerequisite

Properly configure IIS on your Client Access Server (CAS) to host the certificate(s) needed for external and internal access. The certificate recommended for this configuration is a Unified Communications (UC) certificate. You can read more about these different configurations here.

Note: For this article, we will be using a UC certificate that contains 4 Subject Alternative Names (SANs). Our requested certificate’s CN was webmail.shudnow.net. The first SAN name requested was also webmail.shudnow.net. Our request was created using the following EMS command:

New-Exchangecertificate -domainname webmail.shudnow.net, autodiscover.shudnow.net, casserver.shudnow.net, casserver -Friendlyname Shudnow -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true -subjectname “c=US, o=Shudnow Inc, CN=webmail.shudnow.net”

  1. NetBIOS name of CAS (casserver)- used if there is a need/want to connect to services such as OWA using the NetBIOS name of the CAS while connected to the internal network.
  2. FQDN name of CAS (casserver.shudnow.net)- used so we can publish Autodiscover internal URLs to point directly to the CAS.  This name is required if your Exchange Server will be hosting the Unified Messaging rule and you plan on integrating  Unified Messaging into your Office Communications Server 2007 Enterprise Voice envirnment.  If you have an internal PKI, I would recommend leaving this FQDN out and requesting a certificate with this FQDN to avoid exposing your servername to the public.
  3. Autodiscover.shudnow.net – used so external clients can retrieve external URLs to connect to web distributed services.
  4. Intuitivname.shudnow.net – used for services such as Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, web service distribution (OAB, OOF, and Availability). Common FQDNs used are exchange.domain.com, owa.domain.com, mail.domain.com, webmail.domain.com, etc. This article will use the example FQDN: webmail.shudnow.net.

Note: For purposes of this article, the only name in your certificate that is essential for publishing Symantec Enterprise Vault is #4 (Intuitivename.shudnow.net). But since you are requesting a certificate, I would advise you to properly create a certificate with any other names that are required which include #1-4.

You will also want to do the following:

  1. At the minimum, the ISA 2006 Supportability Update is required which is located here.  I would recommend using SP1 instead which is located here.
  2. Create an Exchange Web Listener

ISA 2006 Configuration

You must ensure that you go onto the CAS and export the certificate with its private key and import that into ISA 2006 (Please make sure you have the licenses needed for installing a certificate on multiple servers if required by your certificate vendor). A guide on how to do this is out of the scope of this blog. Once the certificate has been imported on the ISA 2006, ISA configuration can begin. Start by publishing each Exchange 2007 role as needed. For purposes of this article, we will only show how to publish your Enterprise Vault rule and steps needed to configure your OWA publishing rule to get Enterprise Vault to work through OWA.

Enterprise Vault Publishing Rule

For our Enterprise Vault publishing rule, we will go to Servername > Firewall Policy > New > Website Publishing Rule.

Give your Website Publishing Rule a name. Click Next to Continue.

Select Allow. Click Next to Continue.

Since we will be publishing a single Enterprise Vault Server, choose “Publish a single Web site or load balancer.” Click Next to Continue.

If you have installed a certificate for your Enterprise Vault Server, choose “Use SSL to connect to the published Web server or server farm.”  If you have not installed a certificate for your Enterprise Vault Server, choose “Use non-secured connections to connect the published Web server or server farm.”  We did install a certificate on our Enterprise Vault Server, so we will choose the first option. Click Next to Continue.

Enter the Internal Site name of your Enterprise Vault Server.  Then enter the IP Address of your Enterprise Vault Server. Click Next to Continue.

Because the IIS directory name on your Enterprise Vault Server is called EnterpriseVault, you must enter that name in the Path (Optional) field as is displayed in the following screenshot. Click Next to Continue.

Because we will be accessing Enterprise Vault through OWA, we will want to make to enter our OWA URL name in the Public Name field.  For purposes of this lab, our OWA URL will be webmail.shudnow.net. Click Next to Continue.

You will want to select the Listener you created for your Exchange environment. Click Next to Continue.

Select Basic Authentication. Click Next to Continue.

Leave the setting to All Authenticated Users. Click Next and then Finish.

Once you have finished the creating the publishing rule, go into the properties of your Enterprise Vault publishing rule and go to the Paths tab.  Ensure your paths display as follows (which they should if you followed the above correctly). Click OK to Finish.

OWA Publishing Rule

Typically, you create your OWA publishing rule using the Firewall Policy, “Exchange Web Client Access publishing Rule.”  There is a bug that prevents you from setting up Link Translation rules that are needed to get Enterprise Vault to work.  Because of this, make sure you write down all your settings for OWA because we will need to re-create the OWA publishing rule using a regular, “Web Site Publishing Rule.”  We will not go through the entire steps of creating the OWA publishing rule, but will rather go through the modification of this rule to ensure Symantec Enterprise Vault works.

So now we have our two publishing rules:

Open your Exchange OWA publishing rule and go to the Link Translation tab and select “Apply link translation to this rule.”  Click Next to Continue.

We will now want to make some Link Translation Mappings

These mappings include:

How does this work?

A user connects to OWA using webmail.shudnow.net.  They will attempt to access Enterprise Vault.  Because they are connected to OWA, you want them using the webmail.shudnow.net name.  ISA will create a link translation rule so when the user tries to access the Enterprise Vault rule, they will use the webmail.shudnow.net name instead.  But because ISA has the Enterprise Vault publishing rule, ISA knows how to proxy those requests to Enterprise Vault.  The reason we created the Public Name as webmail.shudnow.net for the Enterprise Vault rule is because this rule uses the listener for Exchange which contains a certificate that does not include the certificate that contains the entvault.shudnow.net name.  It does contain the webmail.shudnow.net name though.

Share

Office Communications Server 2007 Enterprise Deployment – Part 1

Now that Office Communications Server (OCS) 2007 is RTM, I thought it would be nice to create an article on how to deploy a single Enterprise Edition OCS Server which is connected to an x64 SQL Server 2005 SP2 Back-End Server. This article will be based off the OCS 2007 RTM version.

This article is to guide you through the entire OCS deployment process from scratch. This article will include the following:

  1. Certificate Services installation
  2. Single Enterprise Front End Server – with information on what to do to get a second Front End Server installed behind a Hardware Load Balancer
  3. Consolidated Edge Server – with information on what to do to deploy a Single-Site Edge Topology or a Scaled Single-Site Edge Topology instead
  4. Dual-Homed ISA 2006 Installation to reverse proxy internal services

Part 1

Part 2

Part 3

Part 4

Part 5

Lab Setup

Guest Virtual Machines

One Server 2003 Enterprise (Standard can be used) SP2 x64 Domain Controller which Certificate Services will be installed as the Enterprise Root Certificate Authority. Exchange 2007 SP1 will be installed with the Hub Transport Server, Client Access Server, and Mailbox Server Role. The purpose of Exchange in this lab is due to the Group Expansion requirement where a Universal Distribution Group must be mail-enabled for it to be expanded within Office Communication 2007.

Two Server 2003 Enterprise (Standard can be used) x86 (x86 required) Member Servers where OCS 2007 will be installed. One of these servers will be the Consolidated Edge Server which will contain 4 NICs.

One Server 2003 Enterprise (Standard can be used) x86 (x86 required) Member Server where ISA 2006 will be installed as a dual-homed box.

One Server 2003 Enterprise (Standard can be used) x64 (x86 can be used) Member Server where SQL 2005 SP2 will be installed.

Assumptions

  • You have a domain that contains at least one Server 2003 SP2 Domain Controller (DC) – This is required due to Exchange 2007 SP1 being installed on the Domain Controller.
  • You have configured the IP settings accordingly for all servers to be on the same subnet. I have provided the IP scheme of my lab below, but this will vary depending on your needs and VMware configuration. One exception to this is one NIC on the ISA Server will belong to a different subnet. This NIC would be the NIC that lives in the DMZ in a production environment.
  • Exchange 2007 Hub Transport Server, Client Access Server, and Mailbox Server are installed on our Server 2003 SP2 DC. Installing Exchange 2007 on a Domain Controller is not a recommended practice for production. But for purposes of this lab, we will do so to consolidate and conserve resources. This article does not go over the installation or configuration of these roles but will go over mail-enabling a Distribution Group(s).
  • You have a SQL 2005 SP1 or SP2 server installed. We will be using SP2 for purposes of this lab.
  • You have a copy of Office Communicator (OC) 2007. We will be installing our copy of OC 2007 on OCS-DC1.

Computer Names

OCS Front End Server – OCS-OCS1

OCS Consolidated Edge Server – OCS-OCS2

Domain Controller / Exchange Server / Root Enterprise CA – OCS-DC1

ISA Server – OCS-ISA1

SQL Server – OCS-SQL1

Configuration of VMware Workstation for Domain Controller / Exchange Server / Root Enterprise CA

There is no official VMWare support for Server 2008 at the time of writing this article. Although we will be using Server 2003 for all Virtual Machines in this lab, the Domain Controller with Exchange 2007 SP1 can be installed on Server 2008. All other machines must be installed on Server 2003. The latest version and build is VMWare 6.0.4 build-93057. There is currently “experimental” support which you will see (if you do use Server 2008) when specifying the Operating System as you create your Virtual Machine. Through my experiences in the past, I did not encounter any real issues related to Windows Server 2008 and VMware Workstation 6.0.2 build-59824. If you do choose to use Server 2008, there will be differences in the installation and configuration of Certificate Services.

Processor: 2

Memory: 1112MB

Network Type Public NIC VMnet8 – Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Virtual Disk Type – System Volume (C:\): VMware SCSI 8GB

Note: In a real-world environment, depending on the needs of the business and environment, it is best practice to install your database and logs on separate disks/spindles. We will be installing Active Directory, Certificate Services, and Exchange 2007 SP1 on the same disks/spindles for simplicity sakes for this lab.

Configuration of SQL 2005 SP2

Processor: 2

Memory: 384MB

Network Type VMnet8 – Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Virtual Disk Type – System Volume (C:\): VMware SCSI 8GB

Virtual Disk Type – SQL Database/Logs (D:\): SCSI 3GB

Note: We will be installing the Database/Logs on a separate volume to see how the OCS installation reacts to seeing extra volumes on the SQL Server.

Configuration of ISA 2006 RTM

Processor: 2

Memory: 384MB

Network Type VMnet8 – Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Network Type VMnet7- Used to mimic your DMZ NIC for external/internet communication

Virtual Disk Type – System Volume (C:\): VMware SCSI 8GB

Configuration of OCS 2007 RTM Consolidated Edge

Processor: 2

Memory: 384MB

Network Type VMnet8 – Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Network Type VMnet7- Used to mimic DMZ NIC for external/internet communication for the Audio/Video Edge Server Role

Network Type VMnet7- Used to mimic your DMZ NIC for external/internet communication for the Access Edge Server Role

Network Type VMnet7- Used to mimic your DMZ NIC for external/internet communication for the Web Conferencing Server Role

Virtual Disk Type – System Volume (C:\): VMware SCSI 8GB

Note: There are few different ways the NICs could be set up on the Edge Roles. I have included a mini-write up below entitled, “Various Edge Server NIC Setups.”

Configuration of OCS 2007 RTM Front End

Processor: 2

Memory: 384MB

Network Type VMnet8 – Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

IP Addressing Scheme (Corporate Subnet) – VMnet8

IP Address – 192.168.119.x

Subnet Mask – 255.255.255.0

Default Gateway – 192.168.119.2

DNS Server – 192.168.119.150 (IP Address of the Domain Controller/DNS Server)

IP Addressing Scheme (DMZ Subnet) – VMnet7

IP Address – 10.10.10.x

Default Gateway – 10.10.10.x

Subnet Mask – 255.255.255.0

Preparation of ISA 2006 Node

Network Interface Card (NIC) Configuration

First thing we will want to do is configure the IP Configuration of both the Public DMZ NIC and Internal Corporate NIC.

We will want to rename our Publc DMZ NIC connection to Public and our Internal Corporate NIC connection to Private. To do so, go to Start > Control Panel. Once in the Control Panel, Double Click on Network Connections.

Now you will be presented with the Network Connections window. This is where you can modify the network properties for each NIC in your server. For your Internal Corporate Connection, rename your Local Area Connection to Internal. Likewise, for your Public DMZ Connection, rename your Local Area Connection to Public. After you have done this, it will look something similar to the following:

Note: Do not forget that part of the assumptions earlier in this article as that you have a properly configured TCP/IP Network where all nodes are properly connected to the TCP/IP Network. Because of this, I will skip the actual TCP/IP Configuration. The IP for the Internal NIC is 192.168.119.153/24. The IP for the Public NIC is 10.10.10.153/24 that would typically have a Public IP NAT’d to this Public IP via Static Network Address Translation (NAT) rule.

Important: In a production environment, you would generally have the Default Gateway on your public NIC. Depending on the communication and configuration of firewalls, you would want to create a static route so your internal communications would go directly to a router on the inside of your network that is more open to communications. This way, you would not have to open ports on your Edge firewall when not necessary. For example, if you were doing LDAPs and your DMZ Edge Firewall blocked port 636. You would need to create a static route so traffic destined to your internal corporate network would go to the internal router that allows 636. You would not need to do this if your DMZ Edge Firewall allowed port 636 and knew how to route to the internal corporate network.

To ensure you reduce the attack surface of your ISA Server, open the Public NIC properties, open the TCP/IP Properties > go into the Advanced NIC configuration settings by clicking the Advanced button. From there, you will navigate to DNS tab and de-select “Register this connection’s addresses in DNS.”

Select the WINS tab and de-select “Enable LMHOSTS lookup” and configure the NetBIOS setting to “Disable NetBIOS over TCP/IP.”

Once you are done configuring the Advanced settings, press OK three times and you will be back at the Network Connections screen. From here, choose Advanced and select Advanced Settings

You will be presented with the Binding Order for your current NICs. Ensure that the Internal NIC is on top by selecting Internal and pressing the green up arrow key on the right-hand side of the dialog. The reason you want Internal on top is because your Corporate communications happen on this NIC and things like DNS are configured on this NIC.

Rename Computer and Join to Active Directory Domain

Make sure you name your ISA box to a name that complies with your naming convention and then join your ISA box to the domain. For purposes of this lab, we will be naming this box, OCS-ISA1. A lot of Administrators believe that joining the ISA box to the domain is a security threat, but that is not so. Please refer to this article explaining why.

Preparation of Consolidated Edge Node

Follow through the same exact steps you did for the ISA 2006 node except for a few things. Instead of 2 NICs, add 4 instead. Also, do not join it to the domain.

A summary of the steps involved consist of:

  • Create 4 NICs
  • Rename the NIC that is wired to the Internal Corporate Network to Internal
  • Rename the NICs that are wired to the DMZ appropriate to their function. Our Access Edge NIC will be named AccessEdge. Our Web Conferencing Edge NIC will be named WebConfEdge. Our Audio/Video Conferencing Edge NIC will be named AudioVideoConfEdge.
  • Assign the appropriate IP Addresses to each NIC. In a production environment, your Audio/Video NIC will need to have a Public IP Address (Non NAT’d IP Address) assigned directly to this NIC. For more information, read here. For purposes of this lab, we’ll assign it an IP on our 10.10.10.x network since we won’t be testing Edge connectivity due to limited resources of our VM environment.
  • Create Static Routes if necessary
  • Disable the Public NIC from registering in DNS
  • Disable the Public NIC’s NetBIOS settings
  • Modify the Binding Order so the Internal NIC is on the top of the list.
  • Rename the Computer
  • Do NOT join it to the domain

Certificate Authority Configuration

Since we are using Windows Server 2003 SP2 for this, we will want to make sure that we have the SP2 binaries and our CD1 for our Windows Server 2003 Enterprise installation. It will be required when we install Certificate Services.

To begin the CA installation, go to Start > Control Panel. Once in the Control Panel, Double Click on Add or Remove Programs.

Click Add/Remove Windows Components.

Place a checkmark in the checkbox next to Certificate Services. You will automatically be prompted with a prompt warning you to not modify the computer name. Ensure your computer name is set correctly before continuing. Once you have your computer name set. Click Yes and then Next to Continue.

Because we will be choosing an Enterprise Root CA, leave the defaults selected. Click Next to Continue.

Note: Choosing an Enterprise Root CA can be considered a security risk to many. Make sure a proper design for a PKI infrastructure is done for both functionality, security, etc. before deploying an internal PKI solution for your organization. I am using an Enterprise Root CA because I am doing this in a test environment and it reduces the amount of resources needed for the lab.

We will name our Root CA OCS-CAROOT. Keep in mind, this is not our machine name. This is what the root certificate’s name will be. Click Next to Continue.

Specify where you want to store your Certificate Database and Logs. For purposes of this lab, we will install it on our System Partition (C:\). Click Next to Continue to begin installation. As stated earlier, make sure you have the SP2 binaries and CD1 of your Server 2003 Installation CD.

If you’re like me and always forget to install Internet Information Services (IIS) prior to installing Certificate Services, you will get the following prompt. Don’t worry, we’ll fix this after our Certificate Services installation completes. If you did get this prompt, Click OK to Continue.

Now our Certificate Services Installation should complete successfully. If you did forget to install IIS before Certificate Services installation began and you received the prompt above, go install IIS by following the instructions here. You will also need your SP2 binaries and CD1 of your Server 2003 Installation CD.

Once IIS is installed, to create the CertSrv subfolder within IIS, type the following command:

Certutil -vroot

Various Edge Server NIC Setups

When going over the NIC configuration of our Edge Servers, it has been noted that we will be using 4 NICs for our Consolidated Edge Server. This would be Method #1 below. As you can see, there are two other ways the NIC Setup could be configured.

Note: The IPs in the above diagram do not represent IPs we will be using in our lab. They are only a representation of what you may see in a production environment. For example, Public IP on Audio/Video Edge NIC, DMZ IPs on your Access Edge and Web Conferencing Edge NICs, and an Internal Corporate IP Address on your Internal NIC.

Method #1 (Recommended)

Every Role has its’ own dedicated NIC. This is recommended due to people having issues in the past with communications when roles share IP Addresses on the same NIC.

Method #2

The Audio/Video Edge Server is the only role that has a Public IP Address. Because of this, it is given its’ own NIC since the subnet it belongs to is different than all other roles. The Access Edge and Web Conferencing Edge Servers are on the same DMZ Subnet. Because of this, they are given 1 NIC to share. The internal NIC is also on a different subnet so its’ given its own NIC. The Internal NIC should always be on a dedicated NIC.

Method #3

It is also possible to use Public IPs on the Web Conferencing Edge Server as well as the Access Edge Server. Because of this, all 3 Edge Server Roles would have Public IPs meaning they can all be on the same NIC. You would then use a dedicated NIC for the Internal NIC.

Summary

Well folks, that is all for Part 1 of this article. For Part 2, I will go over the preparation and installation of a Front End OCS 2007 Server Pool.

Share

MAPI/CDO for Server 2008 and Vista Available

Overview

The Messaging API is a COM-like API that provides access to the contents of messaging stores. CDO 1.2.1 (Collaboration Data Objects, version 1.2.1) is a package providing access to Outlook-compatible objects through a COM-based API. Using either CDO or MAPI, a program can connect to a MAPI store, and then perform operations against that store. Starting with Exchange 2007, Microsoft will distribute the MAPI client libraries and CDO 1.2.1 as a Web download.

System Requirements

  • Supported Operating Systems: Windows Server 2003; Windows Server 2008; Windows Vista; Windows XP
    This package will not install on a system on which any version of Microsoft Outlook or Microsoft Exchange Server 2003 or earlier is installed.

This download is available here.

Share