Friday, November 27, 2009

Issues using DPM 2010 with an Exchange 2010 DAG

I've been "playing", well not really. I've been testing....ya that's it....testing Microsoft's beta version of System Center Data Protection Manager 2010 in conjunction with Microsoft Exchange Server 2010. The tests I've been conducting involve backing up and restoring Exchange servers in a Database Availability Group (DAG). I've also been trying to break the DAG replication by pulling the network cable from a server and watching the outcome. For the most part everything is working quite well however I did come across an interesting issue which deserves discussion.

Exchange 2010 Setup: 4 server DAG with 3 database copies and 1 "lag" copy.
DPM Setup: 1 DPM 2010 server protecting the active copies of my 3 databases in the DAG.
Test procedure: Moved active copy of "Database01" from one server to another (waited about 1-2 minutes) then unplugged the network cable from the server hosting the active copy.

I noticed first off that my lag copy of the database was in a "suspended" state. I've seen this once before but wasn't sure what or why this happened.


(Database "suspended")

I logged into my server hosting the lag copy and looked into Event Viewer. I found an Event ID 117 which stated "the copy of Database01 on this server experienced an error that requires it to be reseeded".


(Database needs to be reseeded)

A few lines down I found Event ID 3145 which stated there was a missing log file which has caused the incremental reseed to fail.


(reseed is required due to missing log file)

I decided the only way to get back on track is to perform an "update database copy" command through the EMC.



I then selected my source server...









I now have a healthy copy of my database....buy why did this happen?

My only rational thought on this one is that DPM ran a synchronization which truncated the logs on my server hosting the active database (jcsexchvan). When I perfomed a "move active database" as part of my tests, it moved to my other server (jcsexchcal). I then performed a physical failure of that server and my 3rd server (jcsexchedm) picked up the active copy. Somewhere in this transition the log file truncation process kicked off on "jcsexchedm". It was at that point my lag copy database on server "jcsexchtor" tried to pull the necessary log files and couldn't find them because the last "Active Manager" in the DAG told it to get them.

This scenario seemed to be a bit of a "perfect storm" case which I was happy to capture. However, during the writing of this article I've tried it again (move active copy, then fail that server) and I get the same result!!

I'd like to get to the bottom of this so if anyone has any insight I'd appreciate feedback. The only thing I can say for sure here is that you'd better make sure you have some form of monitoring software like System Center Operations Manager 2007 R2 to catch these events otherwise you could be in serious trouble.

Cheers.

Sunday, November 8, 2009

Little known fact about load balancing OCS 2007 R2 Edge servers...

I spent some time helping a team member recently with an issue relating to OCS 2007 R2 Edge servers and F5 Neworks load balancers. The effort involved troubleshooting Live Meeting connectivity to remote users. The behavior was such that the remote user would connect to the Live Meeting briefly, then disconnect.

A call to Microsoft support resulted in the engineer indicating port 8057 shouldn't be load balanced. Upon posting to an internal Microsoft forum site, I was informed that this is in fact true. Also, the Microsoft employee indicated the way you should be configuring the web conferencing edge server configuration is to list the actual server names in the internal fqdn entry of the properties of OCS. To do this follow these steps:
  1. Right-click your Enterprise Pool and choose Properties, then Web Conferencing Properties.
  2. You need to add entries for each web conferencing Edge server in your environment. Click the Add button and type the name of the server in the internal dialog box (i.e. serverA.dmz.contoso.com). Then type the external load balanced "shared name" (i.e. webconf.contoso.com).
  3. Repeat the same process for each Edge server you're load balancing to making sure the internal name represents the actual server name.
Now thinking about this setup you would assume the certificate bound to the internal interface should represent the "shared name" of the internal load balanced virtual IP right? Well I'm told the answer is no. If your Edge servers' internal interface fqdn is "ocsedge.contoso.com", you don't need subject alternative names for each server along with it. What strikes me as odd here is that I've just spelled out the need for specifying the Edge server's fqdn within the pool server yet you don't have to "line up" the name in the certificate.

If you investigate the documented firewall rules on the Microsoft web site, port 8057 over MTLS is used. I'm still puzzled as to how you can have MTLS working without the certificate names matching the name(s) defined in the pool settings.

Another poorly documented configuration is the firewall rule required to make Live Meeting work with hardware load balancers and multiple Edge servers. Yes, you need to permit port 8057 from "any" to the DMZ but don't send it through your load balancer. Make sure the rule permits 8057 traffic from the LAN to the internal interfaces of each Edge server.

That's all for now.

Cheers.

Tuesday, October 13, 2009

WARNING about KB974571 and Event ID 12290 -updated

!!UPDATED!! Please see below....

We've found that the update released by Microsoft today (October 13, 2009) to fix CryptoAPI issues will cause OCS services to fail.

The server will log event ID 12290 which says:

"The evaulation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product."

The server will then log event ID 12299 with the error code:

"C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA)"

The KB article can be found at: http://support.microsoft.com/kb/974571

To fix the issue, remove the patch and restart the server.

UPDATE (October 26, 2009) a new update has been released which resolves this issue. It can be found at: http://support.microsoft.com/kb/974571

Monday, October 5, 2009

Exchange 2010 - Archiving and Compliance

There have been a number of discussions I've been in lately which surround the compliance and archiving requirements of customers as they pertain to email, specifically Exchange Server. Many organizations who require messages to be retained and searchable for legal reasons resort to 3rd party technologies such as Symantec's Enterprise Vault platform. These add-on applications provide enhancement to the base functionality offered by Microsoft Exchange (and other email software), but often do so at the expense of the end user....and the pocketbook of the company implementing them.

Let's talk about compliance first...

In previous versions of Exchange you were at the mercy of 3rd party tools to provide a half-baked solution to the legal and regulatory requirements for mail retention and ease of search. One of the most concerning "holes" in Exchange was the ability for a user to send/recieve a message then delete it (soft [deleted items] or hard [shift+delete]), then open the "Recover Deleted Items" feature (a.k.a. the "Dumpster") and purge the messages. If you performed this task before a backup, the message(s) were never retained. If the user's mailbox was moved, the Dumpster information is not retained.



If you were a compliance officer and needed to search a mailbox for content, the process wasn't easy. There were security issues, and knowledge of PowerShell was required. If you needed to search data which had been archived to tape the process could be cumbersome and very time consuming.

Along comes "Dumpster 2.0" in Exchange 2010. Now messages that are purged from the Dumpster end up in a folder called "Purged" which is hidden from view. The user thinks the message has been purged however it remains. A compliance officer can now search the mailbox and discover the data. Since the Dumpster (including the purged items) are part of the user's mailbox now, they move when the mailbox moves and data is always preserved.

Using the new multi-mailbox search tools in Outlook Web Access, a compliance officer can now be assigned a role for discovery (using RBAC) of data and use a familiar, easy to use interface, to perform searches.

Moving along to archiving...

This one has been a hot topic lately. Archiving in Exchange 2010 consists of enabling the "archive" mailbox for a user either using PowerShell or the EMC which resides on the same disk as the primary mailbox. I know when I was in Dallas for Exchange Ignite earlier in 2009 there were a lot of people who were disappointed to hear about the technical details of archiving in Exchange 2010 (including myself....initially). Over time though I've looked back at what our customers are looking for strictly from a requirements perspective and what problems we were attempting to solve. Unfortunately in the process you sometimes trade one headache for another which is commonly the case with 3rd party tools and add-ons.

Looking strictly at why we recommended these tools in the past, the reasons were primarily to overcome issues with performance, stability, data retention, and compliance. In other words it was more about providing a solution to several problems than simply "archiving" for the purpose of recovery. So let's look at these requirements in more detail:

Archive because of PERFORMANCE: Sure, back in Exchange 2003 (and possibly in 2007) it made sense to move mail off of "expensive" fibre channel SAN disk and onto less expensive SATA disk. This also helped with memory management in that Exchange was limited to a 4kb page size; less data to cache, better performance.

The Exchange 2010 answer...don't archive because of performance. You can now run your primary and archive mailboxes on the same disk with the improvements in database schema and disk I/O. Also, the long sync time for Outlook clients no longer becomes an issue since the locally cached copy of the data contains only the data from the primary mailbox and not the archive. You can still access the archive data while "online" through Outlook Anywhere or OWA as well. The biggest misconception here though was that if you removed the data, the problem was solved. Well perhaps it helped due to the page size limitations however it's more about "item count" than actual message size. A folder with 1000 items will suffer long delays when sorting and searching no matter how large each message is. When the count increases, so does the delay. These delays are caused by high IOPS against the ESE and disk.

Archive because of STABILITY: Again, back in previous versions of Exchange you could have users with very large mailboxes and with a very very large number of items per folder. You may have even run up against the 10,000 item count limit in Exchange 2007. Mailbox corruption was a concern and the idea of reducing the size gave the corporate world the sleepy pills to rest with ease.

The Exchange 2010 answer...don't archive because of stability. Mailbox corruption has pretty much been eliminated; and I say pretty much because I've never come across it with 2007 and I've never heard of it....but then again I'm not "all seeing and all knowing"....yet. Item count in Exchange 2010 has been increasaed to 100,000 and the underlying features to help with corruption extend to the various layers from the page entry to the item level. If you've implemented Exchange 2010's new Database Availability Group feature you have multiple levels of corruption protection and self healing.

Archive because of DATA RETENTION: Ah-hah! Now we're onto something. If you need to retain data for longer periods of time you might want to save this information for quite some time. For some organizations this data is an asset up to the first day past the seventh year, then it becomes a liability. You may have deployed an archiving solution to preserve (and purge) data according to your company's retention policy.

The Exchange 2010 answer...Not much different other than the message would be to keep as much mail in Exchange as you can or want to. Use the new retention tags/policies in Exchange 2010 to manage the mailbox size over time.

Archive because of COMPLIANCE: Due to the lack of any sane method of e-discovery in previous versions of Exchange, you would typically install a tool to enhance this portion of the product. These tools often give someone the ability to perform searches using a web interface and will return data in the database. Remember, you won't always get an accurate representation if the user purged the data.

The Exchange 2010 answer...Don't archive because of compliance. Exchange 2010 includes a web interface for e-discovery and using role based security, you can assign permissions to do these tasks.

The four concerns I have with 3rd party tools are as follows:

  1. The cost. These tools are not cheap. Maintenance alone can eat you alive and in times of cost cutting, you could easily win the employee of the month coupon for saving some dough here.


  2. Interoperability. Have you ever been blocked from upgrading to a service pack or new version because the integrated software isn't compatible? These types of blockers can be a real pain for the IT department and could put the organization at risk.


  3. The user experience. This one is the most concerning. You shouldn't implement a platform which changes the user's method for searching and dealing with messages which have been archived. You lose out on existing, and new features such as message preview, the reading pane, and conversation view. Even more annoying is the inability to search/retrieve messages on your mobile phone! Don't degrade the user experience!


  4. Administration. All IT staff are gods anyway so this one doesn't hold much water. The boundless nature of one's brain is truly astounding. Seriously though, another tool, more training....yadda yadda. Junk it!

So that's all for now. I'm tired. Need sleep.

Cheers!


Saturday, October 3, 2009

Messaging Records Management (MRM) in Exchange 2010

I've been reading up qutie a bit the last few days about some of the new features in Exchange 2010 when it comes to managing messages in an organization. I'm happy to say that there is finally a viable solution for enterprise customers who want to implement a retention and archiving policy, complete with logging and the ability to adhere to a compliance policy.

I wanted to write a post about the new features and to have this as a reference for myself and others. There are some new concepts which make up MRM in Exchange 2010. Microsoft's Technet web site does a great job of outlining step-by-step procedures for enabling them...but it does take some time to read.


Overvivew
The MRM features of Exchange 2010 consist of Mailboxes, which have Retention Policies assigned to them. Within the Retention Policies there are Retention Tags which define the rules for managing items.




Retention Tag
A Retention Tag is the at the core of your MRM strategy. The tag contains several variables such as it's name, the folder it will take action on (i.e. Deleted Items folder), how long before the policy is applied (i.e. 90 days), and what action will be taken when the time limit is reached (i.e. move to archive). To create a new retention tag using PowerShell:

New-RetentionPolicyTag "RT-FIN-90-DeletedItems" -Type DeletedItems -AgeLimitForRetention 30 -RetentionAction PermanentlyDelete

or

New-RetentionPolicyTag "RT-FIN-365-Default" -Type All -AgeLimitForRetention 365 -RetentionAction MoveToArchive -IsPrimary $true

NOTE: Don't forget to add the "-IsPrimary $true" to your tag if it's assigned to a new retention policy since the policy needs a default tag. If the primary tag value isn't set, it isn't a default retention tag and the policy creation will throw an error.
Retention Policy
The policy contains the tags you define. You can add and remove them to suit your needs. A retention policy can be assigned to a mailbox or distribution group (maybe even a database but I'm not sure yet). To create a new Retention Policy and assign tags to it:

New-RetentionPolicy "RP-Finance" -RetentionPolicyTagLinks "RT-FIN-90-DeletedItems", "RT-FIN-365-Default"

To add tags to the policy:

Set-RetentionPolicy -Identity RP-Finance -RetentionPolicyTagLinks "RT-FIN-90-DeletedItems","RT-FIN-365-Default","RT-FIN-180-Voicemail"

NOTE: When you add tags to a policy, be sure to "Get-RetentionPolicy | FL" first so you don't accidently forget to assign a previous tag. In other words, when you apply the tags to a policy it will overwrite the settings.

Finally, add the policy to a mailbox:

Set-Mailbox "JasonShave" -RetentionPolicy "RP-Finance"

Seeing it in action...
When you've created your tags, assigned them to a policy, and linked the policy to a mailbox. You can run the Exchange Managed Folder Assistant manually to see how the policy affects the mailbox. The command for this is:

Start-ManagedFolderAssistant


(custom tag called "Tag-DeletedItems")


TIPS
  1. Work with your organization's HR, Security, IT teams, etc. to define the requirements for retention and archiving.
  2. Create a naming convention for your tags and policies.
  3. Test the policies on a mailbox with non-critical data first!
My only complaint thus far is that a GUI hasn't been built for most of the new records management features. For example, you can't create/edit/delete retention tags or policies using the Exchange Management Console or the Exchange Control Panel. This is a great step in the right direction overall though.

Cheers!

Thursday, October 1, 2009

Microsoft XMPP Gateway - released!

Greetings,

Microsoft has released their XMPP gateway software today which will allow OCS users to communicate with other XMPP-based IM platforms. The two platforms currently missing from the Public IM stack are Google Talk and Jabber.

The XMPP gateway software acts like an Edge server (install on a separate box) and will likely support some form of hardware virtualization.

Here are some notes to keep in mind:
  1. Only plain text is supported.
  2. Presence is supported.
  3. You need to be running Communicator R2 as a client (can be connected to an R1 pool).
  4. You can run either R1 or R2 OCS (not LCS).
  5. Custom notes in Communicator are not handled.
  6. Conferencing isn't supported -yet ;-)
Built on industry standard protocols, this software is a welcome addition to Microsoft's UC platform. You can download it here today: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=aa560bfe-9960-473a-bfb8-53bff678cec4

Wednesday, September 30, 2009

Logitech Quickcam Pro 9000 hangs Live Meeting

Just a quick post today. I've noticed lately that I've been having issues with Live Meeting. When I try to change the audio device used for the meeting it simply hangs the application. What's changed recently is that I've been plugging in my Logitech Quickcam Pro 9000 lately. I have all the latest drivers and the camera works great in Live Meeting or Communicator. It's when you go to change the settings where things go south.

Anyway, to resolve it I simply unplugged the camera (since I have an embedded one in the monitor).

Friday, September 25, 2009

HANDS ON: Tandberg Precision HD USB webcam -updated

Well I picked up a Tandberg Precision HD webcam yesterday and thought I'd share my experiences with it. The device is "optimized" to work with Microsoft's Office Communications Server platform and offers HD quality video (720p/24f).



Specifications for the webcam are as follows:
  • 16:9 wide format HD video
  • 1270x720 resolution at 30fps (MS only supports 24fps as per R2 TAP docs [this may have changed recently])
  • All glass optics
  • Auto focus and auto light adjustment
  • Ultra wideband mic
  • Privacy shutter
  • F-stop of 1.7
The camera's requirements are:
  • Windows XP or Windows Vista (also works ootb with Windows 7)
  • USB 2.0 interface
Overall first impressions are that the camera is well built. The hardware has that "Tandberg" quality feel to it. The glass optics make the device much heavier than a traditional webcam but if you're looking for a "1700 MXP experience" with native OCS/MOC and Windows, this is as close as you can get for a fraction of the cost. The USB cable is quite short and I would have liked to see at least a six foot cable attached. If your PC case is far from your monitor you'll need a USB extension cable guaranteed.



Image Quality, etc.
Since my laptop at work isn't a quad core CPU, OCS won't flip on the HD capabilities of the MOC client. With VGA quality video being my only option I have to say that the overall picture quality is quite good. The lighting and color representation is better than your typical home user's webcam. My comparison webcam is a Logitech Quickcam Pro 9000 which also supports HD (2MP). I have found that the Logitech is washed out and doesn't provide the same color depth.

In terms of field of view, I prefer a camera which shows more background. The Tandberg Precision HD webcam is quite tight and needs to be positioned in such a way that you're not cutting off your head in the image. The Logitech is completely opposite and shows everything from top to bottom.

Conclusion
If you have the cash to spend on an executive-style webcam this is an amazing unit. As for the HD quality in OCS, I was finally able to test it. The difficult part though was capturing the image on the other side since my tester was in another city. He was kind enough to snap a digital photo of his TV (also used as a PC monitor). Check it out and see for yourself...


(Click on the image for a larger version)

As you can see there is a great amount of detail in the image. The focal length of the camera is noticable here as well with the foreground image in focus but the background blurred. Very very nice!

Thursday, September 24, 2009

Get your Cisco 7941 to work with OCS with SmartSIP

I posted recently about a product from Evangelyze Communications (http://www.evangelyze.net/) called SmartSIP. In this post I'll talk about how to get your Cisco IP phone to work with OCS and SmartSIP.



Contrary to popular belief I prefer the Cisco phone to many others out there. The overall look and feel of the handset, base, buttons, and display are well thought out and provide some interesting and easy to use features.

For my lab setup I have my OCS Mediation server and SmartSIP collocated on the same virtual machine. By the way, don't  use VM's for production; they're not supported and performance can be terrible. I have a Cisco 7941 IP phone and have downloaded the latest SIP firmware from the Cisco web site (you need to have a valid SmartNET contract to get the code).

NOTE: Be sure to get the Cisco SIP firmware as the SCCP (skinny) won't suffice here.

After installing SmartSIP you will need to activate it and configure it as follows:
  • Change the gateway listening IP address on your Mediation server to 5070. You need to change the port here because SmartSIP needs to use 5061 for SIP Trunk service providers connecting inbound.
  • Change the port for the next hop PSTN gateway to 5055. Again, this port is changed because 5061 is used for SIP trunking.
  • Open the SmartSIP diagnostics application from the START menu
  • Click on the Config (Web UI) tab and select the Microsoft tab
  • Enter the IP address for your OCS server in the OCS SIP Listening Profile
Example:
data="ocs_rtp_ip=10.10.10.127"
data="ocs_sip_ip=10.10.10.127"
  • Click the Save button
Now you need to create a specific location profile for SmartSIP to use when routing calls. What I like about this process is that it leverages the UI in OCS to complete the digit manipulation (with normalization rules). You then route numbers based on the normalized (or de-normalized) numbers. If you're using a SIP Trunk to a carrier such as Thinktel they will accept E.164 formatted numbers so you shouldn't need to change much. If you're sending the call to a voice gateway via IP,  you can route numbers that have been pre-configured within OCS. Here's how:
  • Create a new Location Profile in OCS and call it something like "ss_test_1"
  • Create a new normalization rule for a number you want SmartSIP to route. For example if I wanted to de-normalize a number before routing to my carrier, I would actually use:
Pattern match: ^\+?1780(\d{7})$
Translation: 780$1
  • After you save this rule, go back into your SmartSIP WebUI and click on the Trunks tab.
  • Locate the smartsip_dialoptions_trunks and smartsip_locations_trunks tags and change the value to match your OCS location profile. For example:
data="smartsip_dialoptions_trunks=ss_test_1:sip_cid_type=pid"
data="smartsip_locations_trunks=ss_test_1:ss_test_1"
  • Now click on the General section below and expand it.
  • Change the gateway name to reflect your location profile such as:
gateway name="ss_test_1"
  • In the same section, be sure to enter the IP address of your next hop gateway or SIP provider in the "realm" and "proxy" tags.
Configure the Cisco phone...
Now that you have SmartSIP, OCS, and your voice normalization configured, we can move onto the phones. SmartSIP includes a TFTP server built in which permits your IP phones to download firmware and configuration data for automatic provisioning.

For the phones to find the SmartSIP server you will need to add "option 66" to your DHCP server. I found that on my Cisco 871 router I needed the following syntax in the DHCP pool settings:

option 150 IP 10.10.10.127
  • Log into your Mediation/SmartSIP server and locate the TFTP directory.
  • Populate the directory with your firmware data for the "Cisco 79xx" phone.


You should have something like this (minus the Desktops dir and dialplan.xml)

The Cisco phones need 2 files to operate properly. They are equally important so be sure to pay close attention to the next few steps.

SEP[MAC].cnf.xml
This file is your base configuration file for the phone. It contains information about where the phone needs to connect, what dialplan to use, etc. SmartSIP uses variables in the form of tags to replace the XML values in the file. For example, [USER] and [SERVER_IP] correspond to the extension and SmartSIP server IP. Consult the SmartSIP documentation for more information about what tags are available to you.

Over at Greenwire IT they have a great outline of a basic SEP[MAC].cnf.xml file: http://www.greenwireit.com/blog/2009/09/cisco-7961-and-7941-sip-configuration-sepmac-cnf-xml/

If you're stuck and need a copy of the XML, just let me know. I spent hours and hours trying to get the phone to sign in and provision itself only to find there were invalid values in the sample XML given by default.

Dialplan.xml
This file contains your dial plan for the Cisco phones. You can visit: http://sipx-wiki.calivia.com/index.php/HowTo_configure_Cisco_SIP_phone_with_sipX for a great sample. Be sure to place this in the "Cisco_79xx" directory.

Putting it all together...
Please please please be sure to install Wireshark on your Mediation/SmartSIP server if you haven't done so already. This will provide to be the most critical tool you will ever use. You're probably asking by now, "how do I assign a phone to a user?". The easiest way is as follows:
  • Open Active Directory Users & Computers.
  • Locate your OCS user and click on the Telephones tab of their account.
  • Type in sip:[MAC]@smartsip.local (where [MAC] is the MAC address of the Cisco phone)

  • Click Ok and close out the changes.
  • SmartSIP has a default 5 minute refresh on AD data so you can either wait or simply open the WebUI, click on the Users tab, then click the Update Directory button.
  • Now, open Wireshark and start a trace.
  • Plug in the Cisco phone to a PoE port.
  • Watch for TFTP requests in Wireshark to make sure the phone is at least talking to the server.
Now if you've done everything correctly, SmartSIP will see the request for TFTP data from a MAC address matching a user in AD. It will swap out the [MAC] tag in the SEP[MAC].cnf.xml file along with all the tags within it so they contain the user's name and extension (or DID). You can actually watch the Wireshark trace data to see the file being sent to the phone along with the correct data within it.

The dreaded "UNPROVISIONED" error...
The phone will show a message of "unprovisioned" if your CNF.XML isn't configured correctly. You can typically browse to your phone via http (i.e. http://10.10.10.12/) to view the phone logs. Pay special attention to the phone's log data as it will show you what's wrong. Edit your XML file appropriately to resolve the error.

BONUS: Configure wallpaper on the phone
  • Create a "Desktops\320x196x4\" directory below the "Cisco_79xx" directory included with SmartSIP.


  •  Get a copy of the image you want to edit, open Microsoft Paint (Windows 7 works best) and format the image to a size of 320x196.
  • Save the image as a PNG file (again Windows 7 has MS Paint that does this well now).
  • Create a "list.xml" file as follows:


  • The list.xml file contains a list believe it or not, of images available to the phone.
  • To choose an image hit the Settings button on the phone, select "User Preferences" then select "Background Images". The phone should contact the TFTP server for the data (again Wireshark is the best tool to watch for this).
That's all for now. Cheers!

Tuesday, September 22, 2009

Polycom CX300 (codename "Oak")

Polycom is getting ready to release the Polycom CX300 USB phone which works with Office Communications Server 2007 R2 (QFE2). The handset comes with a more comfortable handset, a 2 line OLED display, and an upgraded speakerphone.



General availability will be at the end of October 2009 and MSRP is suggested to be around $199.00 USD.

I've had the opportunity to work with the beta version of the phone (called the "Oak) for the past six months and I'm happy with the overall quality and feature set. Similar to teathering a Tanjay (Polycom cx700) to your PC, your actions on the phone apply to the MOC client and vice versa. For example, if you place a call with the CX300 phone your MOC client will show the call being placed. Basic phone features such as mute are available from the handset as well.

I'm particularly happy with the overall button feel and handset. This is a big step in the right direction for Microsoft and the end users. I forced myself to use the handset for a 2 hour call the other day and didn't have an issue with fatigue.

Considering the price point and feature set, I can't imagine anyone purchasing the CX200 anymore.

If you get your hands on one of these units make sure you upgrade to QFE2 (July 28th patches). I haven't seen these available on Windows Update yet so you can get them manually from here:


Cheers!

Tuesday, September 15, 2009

SmartSIP fills the gap and more

I spent some time in Redmond recently and had the pleasure of finally meeting Mike Stacy from Evangelyze Communications (http://www.evangelyze.net/). Like many other relationships formed with the power of Microsoft's Unified Communications platform, it was great chatting and talking over Communicator but being there in person has it's benefits as well.


Mike introduced me to a software application called SmartSIP which is the focus of my post today. I'll be posting a lot more in the coming months about this product's capabilities so be sure to check back frequently.

I want to start off by talking about some of the limitations within OCS today. Some of these are truely "deployment blockers" for some of our clients. I'll then talk about how SmartSIP can solve some of these.
  1. The Mediation Server role in OCS can only have one "next hop relationship". This means that if you have a voice gateway connected to a PRI and a SIP Trunk from a provider like Thinktel (http://www.thinktel.ca/), you need two Mediation Servers.
  2. An OCS user can have only one LINE URI (phone number).
  3. Mirosoft's solution to "branch office survivability" is to install an OCS/Mediation server locally.
  4. There is only one IP phone solution available from Microsoft's list of "optimized devices".
  5. You can't connect other IP phone solutions to OCS and there are no OIP certified solutions that support RCC/DF.
  6. The solutions available for shared phone situations often involve the use of a Polycom cx700 IP phone which is not only expensive, it's impracticle for many situations. You wouldn't want to install a cx700 in an elevator or have one in a lunch room. The phone is an "executive style" touch screen IP phone that has great purpose on the desk of a UC enabled user. 
SmartSIP isn't a gateway, it isn't an IP PBX, and it isn't easily classified. You install SmartSIP on your Mediation server (or a stand-alone server) and now you're open to all kinds of new solutions:
  1. You can send calls to one Mediation server and have multiple routes (primary or failover) to various IP endpoints. For example, a call made past the Mediation server can end up with SmartSIP deciding where to send the call based on the number dialed or if the next hop(s) are up.
  2. If you want to assign alternate numbers to an OCS user, you simply define them in the AD user account properties (click the "other" button in the telephone field). SmartSIP has tight integration with Active Directory so it knows that a call to an alternate extension or DID should be sent to an endpoint.
  3. In the case of an outage to OCS, your local IP phones (except the cx700) can talk/register directly to SmartSIP and use it as the routing engine for outbound calls. This means you have a branch office survivability solution without the need for an OCS server.
  4. If you can load a SIP stack on an IP phone you can probably use it with OCS. I'm particularly happy about this feature since many customers may want to leverage the benefits of OCS but don't want to lose the investment in their existing IP phones.
  5. If you want presence on your IP phone you can have it. Actually you can get presence on your TDM phone too with the use of a Portico TVA gateway.
I've posted in the past about how SNOM (http://www.snom.com/) has come up with a brilliant solution for OCS deployments with their firmware that signs into AD/OCS. It isn't without it's challenges as well. For example, you end up with a user's id/password in the phone....so what happens when they change their password? The phone won't work.

The better way to use the SNOM phones is to have them register with SmartSIP using the regular, non-OCS firmware. Also, SmartSIP has a TFTP server built in and will support automatic provisioning of the phones!!

Okay, that's enough for today. Stay tuned for more soon...

Tuesday, August 25, 2009

OCS and the iPhone, now we're talking!

If you have an iPhone and have been frustrated about the solutions available to link up with Office Communications Server 2007 R2 (OCS) then wait no longer (video link below). Modality Systems has created iDialog in the Apple App Store for you at a price of $9.99. While many are shocked at the initial cost, if you weigh the options available from other vendors, it seems somewhat reasonable.

http://www.modalitysystems.com/idialog/


If you have an OCS 2007 R2 Communicator Web Access server you're all set. Typically when we set up these systems we have a split horizon DNS infrastructure so the server URL is the same if you're on the LAN via WiFi or over 3G.

In terms of feature set, most of it is there; just no conferencing (IM), application sharing, or voice callback. The buttons on the bottom of the application show "Contacts", "Chats", "Me", and "Settings".

The Contacts section shows your groups and takes about 5-10 seconds to appear. Each contact is selectable and will show Activity (presence), Calendar, email address, Title, Company, and various phone numbers based on your access level with them. You can tap to IM the person from the same screen. You can also tap a phone number and have the iPhone call them directly.

The Chats section shows any existing IM conversations you're having with people. It is important to note that when you hit the home button, the application doesn't stay running in the background and any conversations will be lost.

The Me section shows your Activity (presence), Note, Location, and phone numbers.

Lastly, the Settings section allows you to enter or correct your authentication settings. You need a domain\username, a password, and the URL to your CWA server.

So far I've found a few bugs with the grouping of IM contacts. Some contacts from other groups show up where they don't belong. Not bad for version 1.0.0 though :)

VIDEO: http://files.me.com/jasonshave/n10xuf (taken with an iPhone 3GS)

Tuesday, August 4, 2009

OCS 2007 Caller ID (name) almost there....

...but not quite yet.

I've been waiting for this feature for quite some time as a lot of our customers see the lack of caller ID being a deployment blocker. Early on in the projects we heard different stories from end users who were frustrated with not having this feature. Some of them wanted inbound to work while others wanted outbound and to have the ability to mask their name.

With the latest OCS 2007 R2 updates on July 28, 2009 we now have caller ID inbound, and outbound can be enabled via the following MS KB article: http://support.microsoft.com/?kbid=972721.

So why "not quite yet"?

First, what you'll notice on a missed call or a voicemail is that the email you recieve doesn't have the name; just the number. I suspect this is due to Microsoft Exchange Server not knowing what to do with the name. Furthermore, I would assume the Exchange team is preparing a hotfix to accomodate the missed call/voicemail with name.....I hope.

Second, I've just finished updating my Tanjay phone to the 3.5.6907.35 firmware and unfortunately it doesn't pass caller ID. Grrrr! Also, if you're not getting caller ID on your MOC client and you have a Tanjay paired with your PC, unplug it and it should work again. It seems as though the Tanjay prevents the MOC client from displaying the name.



If you've ever wondered how it all works, I had a great escalation engineer in India provide me with an explanation.
  1. A PSTN call comes in and goes "ring no answer"; the call hangs up without leaving a message.

  2. OCS communicates with the Exchange UM server using a new "INVITE" command and relays the original information from the "INVITE" that came from the 'gateway' side of the Mediation server. As a side note, many people today are creating special Location Profiles for the Mediation Server so that inbound calls are normalized. This works well for calls that end up reaching users....but again, a missed call will only have the original number, not the normalized one.

  3. The UM worker process performs a lookup in the user's personal contacts to see if it can resolve the number to a name. If successful, a message is generated by the UM server and submitted to the Hub Transport server for delivery to the user's mailbox.

From what I recall at Exchange Ignite earlier this year, there are improved methods for looking up and determining caller ID (name) on onbound calls. As I learn more about this I'll post an update here.


Cheeers!

Wednesday, July 29, 2009

Improving call quality with Dialogic gateways

I've implemented my fair share of Microsoft OCS Enterprise Voice projects and each one has it's own nuances around voice quality. I've gathered a list of the common issues encountered with Dialogic gateways and their fixes which have worked well for me.

_______________________________________________________

Tanjay phone doesn’t produce “comfort noise”


Description: When a user from a “Tanjay” phone calls a PSTN user across a voice gateway such as a Dialogic, the PSTN user doesn’t hear the white noise (comfort noise) typically present on traditional phone conversations. The PSTN user assumes the line has been disconnected and often will say “hello, are you still there?”.

Resolution (Dialogic): Typically you don’t want to enable VAD (Voice Activity Detection) on the gateway however this feature fixes this issue. From the voice gateway click on VOIP then Media and set the VAD to “on”.

_______________________________________________________

Audio levels rise and fall through conversation


Description: When an OCS user calls a PSTN user through a voice gateway, the audio levels rise and fall as though something is adjusting volume. Also at the beginning of a phone call the audio is lower than normal.

Resolution (Dialogic): Set the Automatic Gain Control (AGC) for both IP to TDM and TDM to IP calls to “off”. The reason for this change is that in R2 they included AGC as part of the base application. Levels are automatically adjusted at the client device (and server).

_______________________________________________________

The ringback tone continues to play after the caller picks up

This issue is caused by the gateway not accepting “early media”. With the release of OCS R2, “early media” is a feature which permits OCS devices to complete the call setup quicker. The Dialogic gateway must be set to “Always” for this to function properly.

_______________________________________________________

I hope this helps some of you out there.

Cheers!

Wednesday, July 15, 2009

Undocumented ports for load balancing OCS 2007 R2?

Well it might not be "undocumented" exactly if you're reading the right documentation. Download the .chm file from Microsoft (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703) and you'll be okay whereas some of the online documentation I've seen seems to leave out a few critical ports. For those of you load balancing OCS 2007 R2 Enterprise Edition pools, here is the difinitive port list:
  • 5060 (Client to server SIP communication over TCP. Not required typically.)
  • 5061 (Client to Front End Server SIP communication over TLS)
  • 5065 (Used for incoming SIP listening requests for application sharing over TCP)
  • 5069 (Used by QoE Agent on Front End Servers, needs to be open only if this pool sends QoE data to Monitoring Server)
  • 5071 (SIP requests to Response Group service)
  • 5072 (SIP requests to Conferencing Attendant)
  • 5073 (SIP requests to Conferencing Attendant Announcement Server)
  • 5074 (SIP requests for Outside Voice Control)
  • 135 (To move users and perform other pool level Windows Management Instrumentation (WMI) operations over DCOM)
  • 444 (Communication between the internal components that manage conferencing and the conferencing servers)
  • 443 (HTTPS traffic to the pool URLs)
  • 80 (Used by Tanjay update process. This port is undocumented but required.)

Also the following attributes/settings must be in place:

  • The load balancer must provide TCP-level affinity. This means that the load balancer must ensure that TCP connections can be established with one Office Communications Server 2007 R2 in the pool and all traffic on that connection destined for that same Office Communications Server 2007 R2.
  • The load balancer must provide a configurable TCP idle-timeout interval with a maximum value greater than or equal to the minimum of the REGISTER refresh or SIP Keep-Alive interval of 30 minutes.
  • The load balancer should support a rich set of metrics (round robin, least connections, weighted, and so forth). A weighted least connections-based load balancing mechanism is recommended for the load balancer. This means that the load balancer will rank all Office Communications Servers 2007 R2 based on the weight assigned to them and the number of outstanding connections. This rank will then be used to pick the Office Communications Server 2007 R2 to be used for the next connection request.
  • The load balancer must be able to detect Office Communications Server 2007 R2 availability by establishing TCP connections to either port 5060 or 5061, depending on which is active (often called a heartbeat or monitor). The polling interval must be a configurable value with a minimum value of at least five seconds. The load balancer must not select an Office Communications Server 2007 R2 that shuts down until a successful TCP connection (heartbeat) can be established again.
  • Every Office Communications Server 2007 R2 must have exactly one network adapter. Multihoming an Office Communications Server 2007 R2 is not supported.
  • The network adapter must have exactly one static IP address. This IP address will be used for the incoming load-balanced traffic.
  • The computer must have a registered FQDN. The IP address registered for this FQDN must be publicly accessible from within the enterprise.

Cheers!

Don't collocate CWA with OCS...but if you want to, read on....

So I've come across this several times before.....the client is starting to frown when you say that CWA needs to be installed on a separate server and the 'village of servers' begins to grow. The following steps will illustrate how to install CWA on the same server as OCS. There are a few key steps necessary so be sure to read in detail:

Before I get into the specifics, CWA is not officially supported in a collocated configuration. Now onto the meat.....the 2 primary things you need to watch out for is the multitude of IP's you need on the server and how DNS will react to this. Ultimately you're binding as many as 3 IP's to the same NIC which will accept connections to the OS for port 443 among other things. To avoide collision you need to separate OCS from CWA logically as follows:

  • Install OCS as you normally would (Enterprise or Standard; it doesn't matter).
  • If you're setting up CWA for both Internal and External clients you will need 2 additional IP addresses. Add these IP's to the same NIC used for OCS. Oh and if you're using NIC teaming, you may as well undo the team and go back to one card as this isn't a supported configuration (Audio/Video issues will be seen with teamed NIC's).While you're in the TCP/IP properties of your NIC, be sure to uncheck the DNS registration option.
  • If you added the IP's before disabling automatic DNS registration you may need to go back into your DNS server and remove all the A records corresponding to your server. If not, simply remove the single A record for your server. Then, manually add the A record back in to ensure it isn't 'expired' from the DNS server.

Now you're ready to modify OCS:

  • Open the OCS Admin tool.
  • Expand the pool (or server node if you're using Standard Edition) and right-click the node and choose Properties, then Front End Properties.
  • On the General tab, double-click the Addresses section and change the address to reflect the same one you entered in DNS for the server name (pool IP).
  • Next, click the IM Conferencing tab and change the IP address drop-down to the pool IP.
  • Next, click the Telephony Conferencing tab and do the same then click OK to close the window.
  • Right-click the server name again in the OCS Admin tool, navigate to Properties, then Web Conferencing Server properties.
  • Change the IP address to reflect your pool IP then click OK to close the window.
  • Right-click the server again and choose Properties, then A/V Conferencing properties.
  • Change the IP address to reflect your pool IP then click OK to close the window.
  • Right-click the server again and choose Properties, then Application Sharing properties.
  • Change the IP as you've done above.
  • Finally, open IIS and set the port 80 and 443 listeners for the Default Web Site to the pool IP.
  • Reboot your OCS server and make sure all services start properly.

You're now done with the OCS portion and need to begin on the CWA preparation and installation.

  • Create your DNS entries for CWA. If you have a split horizon DNS you'll want to create an internal A record entry (i.e. cwa.contoso.com) pointing to the second IP of the OCS server. Then you'll want to create another A record entry (i.e. cwa.contoso.com) pointing to the public IP being NAT'd to the third IP of the OCS server. What you end up with is something like:

    10.1.1.10 = ocsserver.contoso.com
    10.1.1.11 = cwa.contoso.com
    215.123.154.222 NAT'd to 10.1.1.12 = cwa.contoso.com

That should be it. Now you have IIS bound to specific IP addresses hosting different web sites (Web Components for OCS, CWA for Internal, and CWA for External).

Cheers!

Friday, July 3, 2009

Passed OCS voice exam!

I finally passed this one. I wrote the beta exam some time last year and failed it by 1 or 2 questions. The beta exam was based on R1 features and had quite a few spelling mistakes and poorly worded questions. I was surprised to notice this exam I just wrote had the same content (R1 and not R2) along with the same mistakes.

Anyway, for those of you wishing to write this exam, brush up on your OCS R1 technologies including the old method of updating Tanjay phones through SharePoint....

Cheers!

Saturday, June 6, 2009

Rethink the way you implement OCS Enterprise Voice

I'd like to start off this post by thanking Mike Stacy at Evangelyze for opening my eyes to this new way of thinking about number normalization and routing. This article discusses the options available to OCS voice implementations surrounding the use of E.164 numbers and the plus sign (+) in your dial plan.

I called Mike a month or so ago and we were talking about how to handle click to call on missed call notifications via email. I noticed Microsoft's missed calls were normalized into E.164 and couldn't figure out how to make this happen. Even if you create a location profile for your Mediation server to handle a 10 digit inbound number transformed into E.164, Mike indicated the missed call is generated with the raw number from the SIP INVITE. The only way I can figure Microsoft makes this happen is at the gateway. They prefix the number with a "+1" on inbound 10 digit numbers. After testing this on my own, it works. However, this brought up the question......why am I adding digits on inbound calls and stripping them on outbound?

This began a debate about what value the plus sign (+) is now that you don't need it in R2. Yes, that's right....you don't need a plus sign in your TEL URI or your normalization rule(s). So you might be asking yourself, why would I care? Why not just add a plus sign to everything?

There are two reasons for this but first I need to explain the difference between a number with a plus sign (+) and one without. When OCS sees a number with a plus sign it treats it as a "global number" and doesn't attempt to normalize it. Rather, it has already been normalized so it will attempt to find a route and call it. This is the most important concept to grasp here which I'll elaborate more on later.

I had a lengthy discussion with a senior escalation engineer at Microsoft recently about the need for the plus sign in OCS voice. The Microsoft engineer indicated I wasn't using E.164 formatting with my OCS solution and that what I was trying to do wasn't supported. So I asked him how you would possibly represent a non-DID such as "extension 2112"? He indicated you could use one of two formats as follows:

Either: +2112
Or use the DID with the extension: +17805552000;ext=2112

Jochen Kunert has an excellent blog about this scenario: http://blogs.technet.com/jkunert/archive/2008/08/19/ocs-2007-dialplan-using-non-did-numbers.aspx

I explained to him that "+2112" isn't an E.164 number. He disagreed. I pointed him to: http://en.wikipedia.org/wiki/E.164 and explained that simply having a plus sign in front of a series of digits didn't mean it was an E.164 number.

When it comes to using the full number with the extension (+17805552000;ext=2112) this creates it's own challenges. First, Exchange UM doesn't like to try and call people by saying their name (when you use the Auto Attendant). Second, there are gateways out there that don't like this format and can't handle digit manipulation. Lastly, I've seen issues when you try to forward your phone to a non-DID in this format (OCS drops the extension number but keeps the "+17805552000"); likely a bug for now but still a pain in the butt.

So back to the crux of the issue and why this is a problem for us....

1. For click to dial scenarios which include missed calls or clicking someone's name in your organization (or federated list), you want to be able to click on a number and have your own organization's normalization rules kick in. If you have a plus sign in the number, it won't be normalized. I mentioned this earlier....OCS will treat these numbers as "global numbers" and it will skip client-side normalization. The end result is that you need to have rules in your gateway to strip the "+1" on outbound local calls.

2. If you normalize all numbers to E.164 with a plus sign, you can't distinguish between local or long distance numbers easily. Here in Alberta we have a 780 area code which has overlapping local and long distance calling zones. This isn't that uncommon really. In order to restrict users from placing calls to 780 numbers which are long distance, we would have to create elaborate routes for all NXX values which are local to the user's phone policy, phone usage record, and route.

Let's humor this scenario quickly. If you have very specific routes for local numbers such as ^\+1780([966])(\d{4})$ you still need to build rules in at your next hop to remove the "+1" because the phone company needs 10 digits on a local call. So now you have twice as much complexity built out in OCS and your gateway(s). Too much to manage....

A better way to design this would be to follow these simple rules:

1. Normalize numbers to a format people would normally use when trying to place a phone call. For example, if somone wants to call a 10 digit local number, don't add a "+1" to it. Also if someone wants to dial a 4 digit internal number you can normalize it to a DID (i.e. 7805551212) or a non-DID (i.e. 2112).

2. Create a catch-all normalization rule to format 10 digit North America numbers with a "1" in front of it.

3. Don't add a plus sign to normalized numbers. This includes your numbers in Active Directory. You want client-side normalization to handle all possible scenarios for dialing. You can put numbers in their 11 digit format (i.e. 17805551212) but leave them as is.

4. At the gateway keep it simple. You shouldn't need to populate your gateway with many inbound or outbound rules. The only exception to this would be for click to dial scenarios where you click on a federated contact who has their number shown as E.164.

So I encourage discussion on this topic as I have spent a lot of time thinking about the pros and cons of this way of designing voice solutions.

Cheers!

Jason

Thursday, May 28, 2009

Auto client update in OCS 2007 R2

I have to give Aaron Tiensivu credit for this entry today. The ability for the OCS server to deliver a new version of the MOC client is an interesting method for keeping your client machines up to date however it does have its own drawbacks as well.

Aaron's blog explains how to set this up and I have included my concise steps below as well:

http://blog.tiensivu.com/aaron/archives/1865-Demystifying-the-Office-Communicator-2007-R2-Client-Auto-Update-feature-and-how-to-setup-it-up.html


  • Download your Communicator patch file (.msp)
  • Log into your OCS server, run the admin tool and right click your server (for standard edition) or your pool name (for enterprise edition) and choose Filtering Tools then Client Version Filter.
  • Click the Add button
  • Set the User Agent Header to OC
  • Populate the version numbers to coincide with the version you want to update. For example, if you have clients at 6907.0 and you want to patch them to 6907.9 then type in the values as per the image below:


  • Set the remaining options as shown above. One difference here is that I like to set the folder name to be equal to the patch I'm upgrading to (i.e. 6907.9).
  • Next, if you're running Standard Edition, create the folder structure show in the image above exactly. For example, on Standard Edition use: C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\6907.9\x32\fre\1033.
  • If you're running Enterprise Edition use your shared file location you specified for your Client Update share: \\servername\client_update\Files\6907.9\x32\fre\1033.
  • Now that you have the file structure in place, copy your msp file to the 1033 folder.
  • Your clients should now update properly. You can right-click on the Communicator icon in the system tray and choose Configuration Information to view the update status.

So here is what I don't like about this process....

1. The user needs to have the right to install software. This update process is not much good to organizations with typical security measures in place.

2. These patches should be managed through the companies patch management strategy. Microsoft now offers patches to the MOC client through Windows Update so my suggestion would be to leverage that method instead.

Oh, and by the way....be sure to install the latest May update (6907.22) because previous versions apparently have a bug which prevent them from contacting the update server process.

Thursday, May 21, 2009

Rock solid Tanjay update!

I've found a fool proof way to update the Tanjay phones with or without signing in.

If you want to update an R1 phone without signing into it:

Add a DNS A record called "ucupdates.domainname.com" where "domainname.com" is the fqdn of your pool name. Point the A record at your Enterprise pool server or Standard edition server. Also add a static WINS entry called "ucupdates" and key in the same IP you did for the DNS record.

If you want to update an R2 phone:

Add a DNS A record called "ucupdates-r2.domainame.com" where "domainname.com" is the fqdn of your pool name. Point the A record at your Enterprise pool server or Standard edition server. Also add a static WINS entry called "ucupdates-r2" and key in the same IP you did for the DNS record.

Cheers!

Jason

Wednesday, May 20, 2009

New layout!

I was getting tired of trying to decipher which text was bold and found the old layout to be too 'skinny' :)

Tuesday, May 19, 2009

Install pre-requisites for OCS - the easy way

Thanks to Tom Pacyk in Portland for this tip...

One of the more annoying installation pains we often feel when we install OCS 2007 R2 on Windows 2008 Server is the multitude of requirements which need to be met. Even when you think you've installed them all (IIS in particular), you inevitably find out there are more and more to install.

Tom's information here: http://www.confusedamused.com/notebook/ocs-2007-r2-front-end-server-2008-requirements-made-easy/ shows you how easy the installation can be when you leverage an XML file for installing pre-requisites.

Thanks Tom!

Cheers,

Jason

Saturday, May 16, 2009

Microsoft Unified Communications Reference Guide: Part 2 (IM)

This post will cover the basic requirements for Instant Messaging features and will outline all the components you will need to install/configure/support the environment.

To get started, lets build out a scenario first. A company has less than 5000 users who need Instant Messaging for both internal and external employees. Connectivity to federated users and Public IM is necessary. The company would like to report on both the usage of Instant Messaging but also be able to archive and extract historical conversations. High availability isn't a requirement today but may become important in the near future.

What infrastructure you need:
  • Office Communications Server 2007 R2 Enterprise Edition
  • Monitoring Server (collocated with OCS pool server)
  • Archiving Server (collocated wtih OCS pool server)
  • Edge Server
  • SQL Server database server (for OCS/CDR/Archive DB)
  • File Server or SAN (for shared file data)
  • Existing PKI infrastructure
  • Firewall with two DMZ networks ("OCS Internal" and "OCS External")
  • Split-horizon DNS infrastructure

For collocation information please see the following Microsoft article: http://technet.microsoft.com/en-us/library/dd425201(office.13).aspx.

The above article suggests you can collocate all the above server roles with the exception of the Edge Server on the same system. It isn't typically recommended that the OCS Server and Archiving Server roles be collocated, however given today's powerful servers I'm more inclined to put it all together.

From a physical server perspective you need:

1 - Dual proc/quad core server with 8GB RAM for OCS/Monitoring/Archiving
1 - Single proc/quad core server with 4GB RAM for Edge (must have dual NIC's)
1 - Single proc/quad core server with 4GB RAM for SQL database (unless you have one already)

You will be building an Enterprise Edition environment which has a defined "pool" name. This name is used by clients when they connect and is important to determine before you begin installing.

My guidelines for creating a pool name are quite simple. I typically ask the customer what their SMTP domain is. Let's say it's "contoso.com". I then ask what their NetBIOS domain name and domain fqdn are. The reason for this is that I need to determine if the domain fqdn is different from the SMTP domain (i.e. Domain fqdn=contoso.local, SMTP domain=contoso.com).

When you create your Enterprise pool name, the setup application will attempt to suggest a pool name by combining your domain fqdn with the name you've given the pool. I always override this because a pool name of "pool01.contoso.local" is of no use to us if we attempt to create SIP URI's with a "contoso.com" suffix. There is a GPO you can set whereby the OCS client application won't deny a logon if the SIP URI suffix is different from the pool fqdn. This is very important as you can't change it easily once you've created the pool name.

DNS Requirements:

1 Internal A record for the pool name = pool01.contoso.com pointing to the IP of the Enterprise Edition server.

1 Internal SRV record _sipinternaltls._tcp.contoso.com pointing to the pool name (i.e. pool01.contoso.com). Set the port to 5061, the priority and weight as default.

1 External SRV record _sip._tls.contoso.com pointing to sip.contoso.com. Set the port to 443, the priority and weight as default.

1 External A record for the Edge server's Access Edge role = sip.contoso.com which should point to the public IP for this service.

Certificate Requirements:

1 Internal PKI certificate with a subject name of pool01.contoso.com and a subject alternative name of server01.contoso.local, and sipinternal.contoso.com.

1 External public CA certificate with a subject name of sip.contoso.com.

IP Address Requirements:

1 IP for the pool server
1 IP for the database server
2 IP's for the Edge Server (1 internal/1 external)

NOTE: If you're NAT'ing the external IP for the Edge server then you should have a public IP as well as a private IP.

File Share requirements:

Meeting Content Share: file://server/meeting_content
Meeting Metadata Share: file://server/meeting_metadata
Application Data Share: file://server/app_data
Client Update Share: file://server/client_update
Address Book Share: file://server/abs_store

Service Accounts:

RTCService
RTCComponentService
RTCGuestAccessUser
RTCEdgeUser (often times a local user if no perimeter domain exists)

Database Requirements:

RTC (persistent user data/contacts/allow & block lists/etc)
RTCConfig (global/pool/computer-level settings)
RTCDyn (transient user data)
LCSLog (used by Archiving Server for IM data)
RTCCDR (used by Monitoring Server's call detail recording and IM stats)
QOEMetrics (used by Monitoring Server's quality of experience data)

Firewall requirements:

Permit 443/TCP from any to Public IP of Edge Server
Permit 5061/TCP from any to Public IP of Edge Server
Permit 5061/TCP from Internal IP of Edge Server to IP of the pool server
Permit 5061/TCP from pool server IP to Internal IP of Edge Server

Now that we have most of the base requirements for the infrastructure, let's talk about the Edge servers. When I first began installing an Edge server I was perplexed at the idea of an "internal" vs. "external" interface and how these would sit on two different networks. After reading some of the OCS documentation I found that you can actually set the Edge server up in three different configurations.

First, the Edge servers can be set up so the external and internal network interfaces are on completely separate networks from the "internet" network and the "lan" network. This means your external interface is on a DMZ network protected by a firewall and using NAT (or not). This also means your internal interface is on a DMZ network protected by the same (or another) firewall.

Q: So how can you have two network interfaces each on separate networks with two default gateways?
A: Well you can do this but I wouldn't advise it. If connectivity is lost for a certain duration, you may have all traffic routed through the wrong NIC. This is due to a feature called "dead gateway detection" and is enabled by default. Read this link for more: http://support.microsoft.com/kb/159168/EN-US/. My suggestion would be to set your default gateway on your external interface and add a static route for any internal networks you need to get to (i.e. pool server, etc.).

Second, you can have both "internal" and "external" physical interfaces on the same network segment. Again, the external interface will hold the default gateway and a static route is required for all traffic destined for the LAN (i.e. your pool server(s)).

Third, you can get away with a single NIC but this isn't supported by Microsoft.

Another interesting case I run into with each project is an over zealous IT administrator wanting to team every NIC he can find. I really don't get this as I've only seen one network card ever fail in my 15 years of working in IT. Often times the network throughout isn't redundant and the team of NIC's are not connected to different switches, etc. etc.

Q: So what about NIC teaming in general for OCS?
A: Well I've had a few Microsoft support cases with Jithendranath Reddy and he is a smart guy! Check this post of people "having no issues" with NIC teaming: http://social.microsoft.com/Forums/en-US/communicationsserversetup/thread/f3dd11d0-a108-4dad-bcbd-976f08bc765b. My response is much the same. Leave it out....don't confuse the design by adding this complexity as it will almost always cause more work than it is worth!

Well this is enough for now. Keep checking back for updates to this post for the latest information.

Cheers,

Jason