Recently I built a new OCS 2007 R2 Enterprise Edition pool for a customer, consisting of 4 Front End servers deployed behind a F5 BIG-IP hardware load balancer to provide IM and Presence and Web Conferencing to a few thousand users. You’d think “no worries right, follow the Deployment Wizard, she’ll be apples”.

Not quite in this case. From this, I learnt a lot more about what it takes to get things off the ground in a large, highly regulated and distributed Active Directory and LCS/OCS environment.

So the objective of this post is to share a few tips with you to help mitigate delays in your deployments in the future.

Back End SQL Database

Make sure you have necessary permissions on the SQL Server (cluster) for the account you are using to create databases in the instance you’re going to use. Note that a SQL Server instance that currently hosts LCS databases cannot be used to deploy the databases for OCS 2007 R2.

Also check with your DBA to see if any minimum database size requirements are in place as part of an existing new database template.

Forest Level Universal Group Memberships

As well as having Domain Admins group membership in the domain you’re deploying the pool in, to create the Enterprise Edition Pool you’ll need either membership of the RTCUniversalServerAdmins group at forest level (the parent domain – created during Forest Prep) or be a member of a group that has had these effective permissions delegated to it (see John’s post for more details).

Service Accounts

Once you’ve created the Enterprise Pool and entered all the necessary FQDNs, specified the back end server and the file shares to use, you’ll want to started installing OCS 2007 R2 on your Front End Servers and adding them to the pool. A few things to watch for here service account wise that you may require change control/approval on.

• The RTCService you create (or utilise from an existing deployment – same name or not) during Front End Server activation must be a member of the RTCHSUniversalServices universal group in forest root.
• The RTCComponentService account must be a member of the RTCComponentsUniversalServices universal group in forest root.
• The RTCGuestUserAccess account you create during Front End Server activation must be a member of the RTCUniversalGuestAccessGroup universal group in forest root.

These are all things that are usually taken care of during the entire deployment process, but could snag you up in a more complicated environment. So when you submit that change request to get RTCUniversalServerAdmins group (or equivalent delegated) membership, send through the names of the service accounts you intend on using also.

Issuing certificates to servers when using the Certificate Wizard isn’t an option

Generally once each Front End Server is installed, added to the pool and activated, we kick on with assigning certificates to these servers. We do this using the Certificate Wizard included with the OCS 2007 R2 Admin Tools.

If you don’t have the necessary rights to wanton request certificates from the CA (e.g. you might only have rights to issue certificates from one particular template) or you can’t request using the Web Server template that the OCS Certificate Wizard uses, you’ll need to either submit CSR files or get your certs from the CA’s web enrolment page. During this deployment, I opted for the later.

Because we generally need to specify a SAN (Subject Alternative Name) or two for things like pool FQDN, machine FQDN and External Web Farm FQDN, we need to make sure these get on the cert. This works a bit differently than in the OCS 2007 R2 Certificate Wizard.

Navigate to the Web Enrolment page of your CA (generally https://serverhostname/certsrv) and click through (in order) the Request a Certificate, Advanced certificate request and Create and submit a request to this CA pages.

Specify the certificate template (Web Server ideally, but if you can only use a certificate template that grants the equivalent or greater specs than this, select that). Fill in all the usual details like you would in the OCS 2007 R2 Certificate Wizard.

Now, here’s the cool part. In the Attributes box at the bottom of the page, you can specify the additional SANs you need. Your string should take the following format:

(san:dns=SN FQDN&dns=SAN FQDN) e.g. san:dns=hostname.domain.com&dns=poolname.domain.com&dns=abs.domain.com

Note that each SAN FQDN is separated by a & (ampersand) sign.

Once you’ve specified your SANs, click Submit.
If the CA is not configured to issue certificates automatically; a Certificate Pending page appears and requests that you wait for the CA administrator to issue the certificate that you requested.
Otherwise, the Certificate Issued Web page appears and you can click Install this Certificate to install the certificate.

This step installs the certificate to the User container in the Certificates MMC snap-in, so make sure to properly move it to the Machine container so you can assign it to your Front End servers.

Conclusion

You won’t come across a lot of these issues in every Enterprise Edition pool deployment you do, but it’s worth being aware of them for those peskier, more locked down environments.

If anyone has any questions regarding anything I’ve mentioned, feel free to post it in the comments section.

- Justin Morris, Modality Systems

To provide a seamless experience for your staff working remotely outside the corporate LAN in addition to an Edge Server, OCS 2007 R2 (and R1) also requires a reverse proxy in your DMZ/perimeter network to publish your Web Components Server role (IIS) of the Front End Server. This is to provide a few things:

• Address book download (GAL search capabilities) in Office Communicator.
• Distribution group expansion within Office Communicator.
• Meeting content download during a web conference in Live Meeting and;
• Download of device firmware update for Office Communicator Phone Edition (OCPE – Tanjay) devices.

If the client applications (Office Communicator and Live Meeting) can’t retrieve these items, you will experience problems such as:

• The much maligned “Cannot synchronise corporate address book” error in Communicator.
• The inability to expand distribution groups in a users contact list in Communicator.
• PowerPoint presentations, whiteboards and any other uploaded content will not display in Live Meeting and;
• Any OCPE devices external to the corporate LAN won’t be able to get new firmware updates.

In addition to this, a reverse proxy would usually be required to publish other services such as Communicator Web Access, Outlook Web Access/App, SharePoint, etc. ISA Server 2006 is your best weapon of choice for this purpose, but the reverse proxy requirement for OCS can also be achieved using other firewall/web publishing devices you might have.

Today I’m going to focus on a neat trick you can utilise with ISA Server to use 1 less certificate, FQDN and IP address when publishing your OCS IIS directories by utilising an existing URL.

All the requirements and steps for setting up ISA Server are detailed in the Microsoft documentation. The focus of this post won’t be to go into the detail of how to configure rules and web listeners in ISA. I’ll assume you’re all cluey enough to get that bit sorted out.
I’ll use publishing SharePoint with OCS as an example, but this could be adapted to be used with the other resources as listed above, depending on your publishing method.

Because we are specifying explicit URL paths to forward web requests to OCS, we can layer this on top of a rule that already forwards requests to the /* of your URL and use its FQDN as well. The end product should look like this:

The only requirement for this scenario is that the underlying URL must be using a web listener that supports No Authentication in the Authentication tab of the web listener. You can’t use a URL that is being published using ISA Server forms-based authentication or another type of authenticaiton, because OCS requires No Authentication to work.

Today I’ll go through the process of completing the following tasks:

1. Changing your External Web Farm FQDN on your OCS pool to match the desired URL.
2. Configuring your OCS web publishing rule to respond to requests on the new URL.
3. Specifying explicit required paths on the new URL.

I recommend that you either test this configuration in a lab environment first or schedule an outage window to implement this as it may cause an interruption of service to the existing URL you’re utilising.

Changing your External Web Farm FQDN

Firstly, you’ll want to identify which FQDN you’re going to use for the OCS External Web Farm FQDN from your existing FQDNs published on ISA Server. Let’s say for example sharepoint.contoso.com.

1. Log on to the Standard Edition server or Enterprise Edition server in the pool with an account that is a member of RTCUniversalServerAdmins group or has equivalent permissions
2. Open a command-line prompt.
3. Navigate to the \Program Files\Common Files\Microsoft Office Communications Server 2007 directory.
4. To set the external URL for the Web farm, type the following command:

5. Lcscmd /web /action:updatepoolurls /externalwebfqdn:sharepoint.contoso.com /poolname:<poolname>

This will update the WMI parameters for the pool and allow OCS to respond to requests to the FQDN specified.

Configuring the OCS web publishing rule to respond to requests on the new URL

As you progress through the Web Publishing Rule Wizard as detailed in the documentation, you’ll need to configure the fields on the Public Name Details page with the FQDN of the existing service you’re going to utilise (SharePoint in our case).

Specify the path /Abs/* for now, we’ll specify more paths later.

Continue with configuration of the web publishing rule to the Select Web Listener page and select the web listener already configured for the FQDN you want to use.

Continue configuration as detailed in the documentation.

Specifying explicit required paths on the new URL

After you’ve created the web publishing rule for OCS, open the Properties dialog and select the Paths tab.

In addition to the /Abs/* path you added during creation, add the following additional paths for this web publishing rule:

/RequestHandler/*

/GroupExpansion/*

/DeviceUpdateFiles_Ext/*

/etc/*

Your paths should look like this (they might be in a different order, this is ok):

And the rule you have created for publishing SharePoint should look like this:

This rule then effectively becomes a “catch-all”, and must be ordered after the OCS publishing rule in your ISA Server firewall policy (as illustrated in the first image in this post).

By creating these two rules in ISA Server, we ensure that only requests from Office Communicator and Live Meeting to the explicit paths we have specified for OCS are proxied to your OCS 2007 R1/R2 pool/front end server, and all other requests are proxied to your SharePoint server (or whatever other service you choose).

This results in only utilising the one IP address, SSL certificate and FQDN, thus cutting down on costs and management.

Feel free to post any questions to the comments section.

- Justin

When it comes to developing against Office Communications Server, choosing the appropriate API can be a task in itself. The number of available APIs can be a bit overwhelming at first glance, and the selection task is not helped by concerns over which APIs are compatible with which release.

This post aims to shine a small light on each of the APIs, and give an idea of which APIs can be used against which version of Office Communications Server. (Disclaimer: version compatibility was determined by the information available on MSDN at the time of writing, and a small amount of testing)

The APIs currently available are:

Client side:

• Office Communicator Automation API (2007 and R2)
• Unified Communications Client API (2007 and R2)
• Unified Communications AJAX API (2007 and R2)
• Communicator Custom Tabs (2007 and R2)

Server side:

• Unified Communications Managed API 1.0 (2007 only)
• Unified Communications Managed API 2.0 Core (R2 only)
• Unified Communications Managed API 2.0 Workflow (R2 only)
• Unified Communications Managed API 2.0 Speech (R2 only)
• Office Communications Server Application API (2007 only)
• Office Communications Server Application R2 API (R2 only)
• Office Communications Server Management API (2007 and R2)

 

Office Communicator Automation API (2007 and R2)

This is a client side COM API that allows an application to automate the running instance of communicator. Communicator 2007/R2 must be installed on the target machine, and must be running in order for an application to make use of it.

Using this API, a custom application can perform the same tasks as communicator – for example:

• Sign into/out of communicator
• Display a list of contacts, with presence information (including the signed-in user’s presence) and profile information
• Manage contacts and contact groups
• Start voice/video/IM conversations (these will open a new Communicator conversation window, as if the call had been initiated from Communicator)
• Send text to an IM conversation
• Manipulate the main Communicator window (size, positioning)

This allow the developer to integrate presence and “click to communicate” functionality into applications, and also allows for the possibility of passing information from one instance of an application to another – for example, User A initiates a conversation about a customer with user B. User B’s application updates to show the customer records of the customer being discussed.

 

Unified Communications Client API (2007 and R2)

This is a client side COM API that allows custom applications to be written that include communication capabilities, without the restriction of having Communicator installed on the target machine. Although more complicated to use than the Communicator Automation API, it does allow full control over communications capabilities.

To contrast this API and the Communicator Automation API this example should give a flavour of the differences:

• When starting a conversation in an application using the Communicator Automation API, a new Communicator conversation window is opened (i.e. the conversation window is not integrated into the application).
• Using the Unified Communications Client API, we could start a conversation from an application, and also embed conversation windows into the application. While this is more development work, it provides a much more integrated feel.

This API allows the developer to integrate all of the same capabilities that Communicator provides into a custom application. As well as this, it gives the developer a lower-level insight into the SIP messages – for example, SIP headers can be examined.

 

Unified Communications AJAX API (2007 and R2)

This API allows custom web pages to be created that include communication capabilities. It requires that Communicator Web Access be enabled in the OCS environment.

The API allows the developer to include the following capabilities into web pages:

• Presence subscribing/publishing
• Contact management
• Start and accept IM conversations/conferences (no voice/video)

 

Communicator Custom Tabs (2007 and R2)

Custom Tabs can be added into communicator. These host an Internet Explorer control, so can be used to display a web page. The web page is sent the SIP URI of the signed-in user, and also the SIP URIs of any selected contacts.

This allows the developer to display further information related to the user and the user’s contacts, within the main communicator window. Not strictly an API, custom tabs are enabled through registry settings and xml config files.

 

Unified Communications Managed API 1.0 (2007 only)

This is a server-side API that can be used to create applications that interact with OCS, and appear as users with their own SIP URI. This is the API that is typically used for creating query/response agents (Bots), or Broadcast IM bots that send IMs in response to certain events.

This API allows the application to behave as a user, with the following limitations:

• There is no support for querying presence
• IM is the only modality supported
• There is no support for conferencing

Using this API, the developer can create applications that:

• Provide an end-point for users to query to get information – for example, a bot that responds to queries for stock prices
• Broadcast information to users when certain events happen – for example, when a stock price falls below a certain threshold

 

Unified Communications Managed API 2.0 Core (R2 only)

This API builds on UCMA 1.0 by adding the following support:

• Querying presence
• Audio
• Conferencing

As well as the application scenarios that UCMA 1.0 enables, this API allows the developer to create applications that:

• Ask users for information as part of a workflow – for example, User A submits an expense claim, the bot starts a conversation (IM or Voice) with User B when they are available, provides details of the expense claim, and asks User B for authorisation
• Initiate or join conferences – for example, schedules a conference and IM’s participants 15 minutes beforehand

 

Unified Communications Managed API 2.0 Speech (R2 only)

This API provides Speech Recognition and Text-to-Speech capabilities for applications, allowing the developer to create applications that:

• Place a voice call, and read textual information to the call recipient – for example, the contents of an email
• Understand and respond to voice commands

 

Unified Communications Managed API 2.0 Workflow Activities (R2 only)

Windows Workflow Foundation is a technology for building applications, which allows business processes to be modelled as Workflows (think Flow Charts). Each step in the workflow relates to an “Activity”, which is a block of code that performs a specific task – for example, email a user using this template. This (in theory) cuts development time and makes changes to the business process easier to accommodate.

The UCMA 2.0 Workflow Activities are pre-defined workflow activities which provide the following capabilities (and more):

• Answer an incoming call (Voice or IM)
• Ask the user questions
• Respond to commands

This primary scenario this API enables is Interactive Voice Response applications.

 

Office Communications Server Application API (2007 only)

This API allows modification of standard OCS functionality at the SIP message level.

Using this API, a developer can create applications that inspect messages as they pass through a given server, and take actions based on information in that message, for example:

• Modify the message in some way – for example, add a disclaimer to the body text
• Reject certain messages – for example, those that contain hyperlinks
• Log messages to a database
• Perform routing tasks

 

Office Communications Server Application R2 API (R2 only)

As above, but 64 bit, and with some minor additions.

 

Office Communications Server Management API (2007 and R2)

This API provides the ability to manage an OCS installation, via WMI. It can perform a huge range of tasks, for example:

• Modifying users Communicator contacts and groups
• Modifying edge server settings

The relevant WMI classes are installed on any machine that has the Office Communications Server administrative tools installed.

 

I hope this clarifies the options available. Quite a few already, and I haven’t even mentioned the APIs available to integrate with other server products e.g. Exchange, SharePoint, Live Meeting…!

- Paul Nearney, Modality Systems

For two years now Microsoft has been building its assault on the global corporate telephony market. What appeared to be a bold, new approach has now been ratified by the latest Gartner research.

Some may say that the big news is Microsoft making it on to the Gartner Magic Quadrant for Corporate Telephony – (report published on 8th August 2008) – albeit only in the “Visionaries” quadrant. However, the real news is in the text of the report itself.

The report’s introduction immediately positions the importance of Unified Communications as a framework in which Telephony is merely a component. This is a critical distinction that should not be overlooked.

“…decisions to invest in unified communications take precedence over telephony”

“…although companies are still deploying PBX and IP telephony, most should make the decision in the context of a broader unified communications strategy”

With respect to Microsoft, the report is specifically talking about Microsoft’s Unified Communications platform product Office Communications Server (OCS) 2007 emerging as a credible contender for corporate voice communications, while cautioning that OCS does not offer a like for like replacement for PBX and IP-PBX solutions.

This should come as no surprise to anyone following the entrance of Microsoft into the Voice market. Gurdeep Singh Pall (Sr. VP of Microsoft’s UC division) summed it up at Voicecon last year by saying “Microsoft is not building a replacement PBX, it is building an alternative to a PBX”.

Microsoft’s placement in the visionaries quadrant is a powerful statement and will surely guarantee their inclusion in future voice RFP’s and tenders – but is the position as a Visionary while scoring low on the “Ability to Execute” axis a major concern? The report also cautions that OCS 2007 “lacks key [PBX] functionality, questions scalability and considers OCS 2007 expensive as a voice only solution.”

Our opinion is “absolutely not.” The report talks about the changing role of the IP PBX and highlights 2010 as the year many users will be using an integrated set of collaboration tools beyond telephony, encouraging companies to consider their telephony partners in the broader context of a UC strategy.

It’s only been 10 months since OCS 2007 officially shipped, so it’s not surprising that widespread adoption has been a slow burn rather than a wildfire. History tells us that Microsoft is extremely good at iterating on a product strategy over multiple releases and any questions around functionality and scalability will be addressed over time.

One cannot dismiss the significance that Microsoft, as the industry leader in corporate desktop software, will play over the coming years with current and future versions of Office Communications Server. If you’re serious about a long-term UC strategy that includes telephony, it’s time to give that OCS pilot project a kick start to see what all of the fuss is about.

 

We recently implemented the full Microsoft Unified Communication (UC) solution at Modality Systems to provide Voice and Unified Messaging (UM) capabilities for our employees.  

At present, our production email system is a Hosted Exchange 2003 service run by a 3^rd party hosting company, and we needed to integrate our internal Exchange 2007 UM deployment with our hosted Exchange service.

The solution we developed to solve this problem also broadly applies to organisations who are running a pilot or proof-of-concept Exchange 2007 UM systems (running in a separate AD forest) and want to forward the voice mail and missed call notifications to their user’s production mailboxes.

It sounds like it should be straightforward enough, until you dive into the details.  We realised that we effectively needed to forward email between two independent messaging systems that were hosting identical SMTP address spaces.

There are number of advantages to deploying the pilot using the same SMTP address space as the production system

• The display of Office Communicator presence information in Outlook, SharePoint and other applications requires the user’s SIP address and SMTP address to match (there are exceptions to this rule, but using workarounds complicates the configuration).  
• The Exchange UM mailbox SMTP address needs to match the user’s SIP address in order to integrate the OCS 2007 Voice system with the Exchange UM system (specifically, the user’s OCS SIP URI must match their EUM proxy address)
• A production pilot will be more successful if it integrates with the user’s daily experience seamlessly.  Giving user’s multiple addresses and multiple accounts will almost  guarantee that the user will not use the pilot system effectively.

Here is a summary of how this was achieved. 

1. Configure the pilot OCS 2007 system to integrate with the pilot Exchange 2007 system for Voice Mail and Unified Messaging.  Details of how to do this can be found here.
2. On the pilot Ex2007 system, we set up our @modalitysystems.com domain as an Internal Relay Domain
3. Next we created a Send Connector using the Address Space of modalitysystems.com and a Smart Host pointing to the FQDN of our production email system.   Important:  Do not just edit the existing connector as you will need a “*” address space connector to send all your other email out through.   (This now meant that anything sent to an address of *@modalitysystems.com that didn’t exist in the pilot Exchange 2007 Global Address List would now be sent out externally to the production system for delivery.)
4. Next, we created Contact Objects within the pilot environment a gave them new “UM” addresses. We used the format of username.um@modalitysystems.com, but you can use whatever format you want as long as the user portion is different from the actual GAL address.
5. Next the new Contacts were set up as forwarders on each corresponding Exchange 2007 account.
6. Finally, we needed to add the new “UM” SMTP addresses as secondary addresses for each of our users in the production email system. 

Now, UM email received by pilot mailboxes would be automatically forwarded to our user’s production mailboxes.  This provides a limited version of the UM offering, giving you the basic voice mail & missed call service into our production Exchange 2003 accounts.  

These are the limitations of this approach:

• This solution only provides a way to receive voice mail and missed call notifications.  The other features of Ex2007 UM such as calendar integration and “play-on-phone” will not be available since the UM system is integrating with the non-production mailbox.
• A clean-up process of the pilot mailboxes may be required since users will not typically connect to these mailboxes.  Voice Mail messages can pile up over time with no way for the user to delete them unless you give them access to this mailbox via, e.g., OWA.  The Managed Folders feature in Exchange can be used to automate this process. 

We’ve been using this for a couple of months now and it provides a great interim solution until we migrate from hosted email to our own internal Exchange system.

-Nick Seagrave, Modality Systems

There are two kinds of people in this world:  Those who have tried to install and configure the "Microsoft Office Communicator, Phone Edition Software Update Service" (aka, the Tanjay Update Server)… and those who haven’t.

If you have, you’re probably smirking because you know what I’m talking about.  If you haven’t yet, I might suggest you let sleeping monsters lie. 

Though if you’re a brave knight and want to test your luck, help is available.  I’ve been working with Microsoft and we’re documenting solutions to the most common problems. 

TomL (LCSKid) has posted our work over on his blog : http://blogs.technet.com/toml/archive/2008/06/02/update-server-problems-with-configupdateserver-vbs.aspx

Thomas Lee (from Global Knowledge) also has an excellent post on his blog that covers the infrastructure requirements.  http://cacorner.blogspot.com/2008/05/getting-tanjay-working.html

If you have any questions or issues not covered in these blog posts, please post a comment or email me.  We’re tracking the problems and will post updates with solutions.  Thanks!

-John Lamb, Modality Systems

We’ve just been through the exercise that every IT consultant / engineer / analyst goes through at some point:  The reverse engineering of permissions applied on active directory objects. 

Hopefully this post will spare you the tedious task.

In this particular case, we needed to give a non-Domain Administrator the ability to install and activate an OCS 2007 server. 

The OCS installation wizard (setup.exe) and command-line configuration tool (LCSCmd.exe) both give you a simple way to delegate installation & activation of OCS Servers.  The challenge however, was that our client wanted to know “what, exactly” was being delegated.   It’s a fair question.  What would be the point of having a Domain Admin delegate permissions to a user, if the user received 90% of the privileges of the Domain Admin as a result of the delegation? 

Presumably, the OCS delegation wizard only delegates the minimum permissions required to do the job.  That is what we set out to prove.

OCS Installer Group Required

First, you must pre-create an AD security group that will receive the delegated permissions.  Let’s call this “OCSInstallersGroup” for the purposes of the example.

Any user who will perform installation and activation of OCS servers will become a member of this group.   The delegation wizard delegates permissions to this group, not to an individual user.

OCS Service Accounts Required

Before running the delegation wizard (or LCSCmd) you will also need to know the names of the OCS SIP Service and OCS Component Service accounts.  These are AD user accounts that are being used to run the various OCS Server services.  If this will be the first OCS Server in the domain, you will need to pre-create these user accounts. 

• OCS SIP Service Account (default: RTCService)
• OCS Component Service Account (default: RTCComponentService)

Delegation Wizard Inputs

The delegation wizard must be run by a user who is a member of the Domain Admins group in the domain where we are installing the OCS Servers.

The wizard requires 5 input variables:

1. TrusteeGroup:  The name of the OCS Installer Group, e.g., OCSInstallersGroup
2. TrusteeDomain:  The domain where the group exists, e.g., europe.yourcompany.com
3. SIPServiceAccount:   The name of the OCS SIP Service account, e.g, RTCService
4. ComponentServiceAccount:  The name of the OCS Component Service Account, e.g., RTCComponentService
5. ComputerOU:  The DN of the OU where the OCS Servers are located, e.g., OU=OCS2007,OU=Servers,DC=europe,DC=yourcompany,DC=com

Delegation Wizard Outputs

The wizard performs the following tasks:

1.  The TrusteeGroup is added to the Following Groups:

• RTCUniversalGlobalWriteGroup – Members have write access to RTC global settings
• RTCUniversalGlobalReadOnlyGroup – Members have read access to RTC global settings

(The OCS Global Settings are AD objects typically stored in the configuration partition at: CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=yourcompany,DC=com.   In some cases, the Global Settings may be stored in the Root Domain Partition instead.)

2.  The TrusteeGroup is granted Read and Write permissions* to the ComputerOU (the OU containing the OCS Servers).

3. The TrusteeGroup is granted Read/Write Service Principal Name (SPN) permissions* on the OCS SIP Service Account object

4.  The TrusteeGroup is granted Read/Write Service Principal Name (SPN) permissions* on the OCS Component Service Account object.

*  If you would like to see a list of the specific Access Control Entries (ACEs) that are applied in Steps 2 – 4, we’ve documented them here.

Analysis

Our findings were pretty much what we expected.  The person installing OCS needs to be able to create the Pool and Server objects in the Global Settings and they need to be able to register new Service Principal Names in AD (Use a utility like SetSPN.exe to see what these are).  

We were happy with this… and more importantly, our client was happy with this. 

John Lamb, Modality Systems

Technorati Tags: office communications server 2007, active directory, delegation of administration

Special Thanks to Steven Westwell for his knowledge and experience with Windows and Office localisation.  His assistance was instrumental in discovering the information contained in this article.  Steven’s blog can be found here: http://stevenwestwell.wordpress.com/2008/02/21/ocs-localisation/

Generally speaking, the documentation for the Office Communications Server 2007 product suite is very good.  One of the areas that is lacking however is information required for large-scale client deployments.

We’re currently in the midst of an 80,000 user global roll-out of the Office Communicator 2007 and Live Meeting 2007 clients.  In the absence of comprehensive documentation on language localisation (or “localization”, depending on which side of the Atlantic Ocean you’re on), we’ve done some extensive testing.  Here’s what we’ve learned:

I.  First things first

There are 3 client components required for OCS 2007:

1. Office Communicator 2007 – supports IM and Presence, Audio/Video conferencing, Telephony Call-Control, Voice calls, and File Transfer.
2. Live Meeting 2007 – supports Web Conferencing, Audio/Video conferencing, Whiteboard, and other forms of data collaboration.  This client is also required if you plan to deploy the RoundTable device.
3. Outlook Add-In for Conference Scheduling – This enables a user to schedule conferences using the Outlook calendar. 

Office Communicator 2007 and Live Meeting 2007 behave differently with respect to language localization.

II.  Office Communicator 2007 – Language & Localisation Settings 

Office Communicator 2007 now supports the full set of 37 Microsoft Office languages:

	Office Communicator 2007 Language	Hex Value	Decimal Value
1	Arabic – Saudi Arabia	0×401	1025
2	Bulgarian	0×402	1026
3	Chinese (Simplified) – PRC	0×804	2052
4	Chinese (Traditional) – Hong Kong SAR	0xC04	3076
5	Chinese (Traditional) – Taiwan	0×404	1028
6	Croatian	0×41A	1050
7	Czech	0×405	1029
8	Danish	0×406	1030
9	Dutch – Netherlands	0×413	1043
10	English – United States	0×409	1033
11	Estonian	0×425	1061
12	Finnish	0×40B	1035
13	French – France	0×40C	1036
14	German – Germany	0×407	1031
15	Greek	0×408	1032
16	Hebrew	0×40D	1037
17	Hindi	0×439	1081
18	Hungarian	0×40E	1038
19	Italian – Italy	0×410	1040
20	Japanese	0×411	1041
21	Korean	0×412	1042
22	Latvian	0×426	1062
23	Lithuanian	0×427	1063
24	Norwegian	0×414	1044
25	Polish	0×415	1045
26	Portuguese – Brazil	0×416	1046
27	Portuguese – Portugal	0×816	2070
28	Romanian	0×418	1048
29	Russian	0×419	1049
30	Serbian – Latin	0×81A	2074
31	Slovak	0×41B	1051
32	Slovenian	0×424	1060
33	Spanish – International	0xC0A	3082
34	Swedish	0×41D	1053
35	Thai	0×41E	1054
36	Turkish	0×41F	1055
37	Ukrainian	0×422	1058

To set the Office Communicator language manually, first install the Communicator 2007 Multi-Language User Interface (MUI) Pack, which is available for download here:  http://www.microsoft.com/downloads/details.aspx?familyid=86DE1E77-3406-475A-9271-24F507E20972&displaylang=en

Then, use the Options > General configuration page to select the language as shown in this screenshot. (Note that Communicator must restarted for the changes to take effect.)

Optionally, the Office Communicator 2007 language can be set programmatically, by modifying the following registry key:

HKCU\software\Microsoft\Communicator\Language : REG_DWORD : <language code>

If you are planning to set the OC 2007 language to be machine-specific (rather than user-specific) , such as during the OS build process, you could use the following registry key instead:

HKLM\Software\Microsoft\Communicator MUI\Default Language : REG_DWORD : <language code>

III.  Live Meeting 2007 Console – Language & Localisation Settings

In the current version of the software, there is no integration between language settings for OC 2007 and LM 2007.   According to a source at Microsoft, this will change for the next version of the Live Meeting client when the LM client is re-written “from the ground up”.

The Live Meeting 2007 Client (aka LM 2007 Console) supports the following 14 languages:

	Live Meeting 2007 Console Language	Hex Value	Decimal Value
1	Chinese (Simplified) – PRC	0×804	2052
2	Chinese (Traditional) – Taiwan	0×404	1028
3	Danish	0×406	1030
4	Dutch – Netherlands	0×413	1043
5	English – United States	0×409	1033
6	Finnish	0×40B	1035
7	French – France	0×40C	1036
8	German – Germany	0×407	1031
9	Italian – Italy	0×410	1040
10	Japanese	0×411	1041
11	Korean	0×412	1042
12	Portuguese – Brazil	0×416	1046
13	Spanish – International	0xC0A	3082
14	Swedish	0×41D	1053

 

Note: There is no MUI Pack for LM 2007.  These 14 languages ship as part of the base LM 2007 installation executable.

Unfortunately, there is no way to manually set the LM 2007 client language.  If the Windows 2000, Windows XP, or Windows Vista operating system has a language pack installed, then the LM 2007 client will automatically detect the Operating System’s language and use that.  This is the language that is specified in Control Panel > Regional and Language Settings, as shown in the screenshot below:

For example, if you have the English, French, and Japanese OS language packs installed, you would select the regional option for the desired language.  If you only have a single language pack installed(for example, only Japanese), the LM 2007 console will use Japanese by default.

This means that you must have an OS Language Pack installed in order to change the LM 2007 language… and the LM 2007 client cannot be in a different from the OS language.

This also means that you could have Office Communicator set to a different language than LM.  The best practice for deployments would seem to be to automatically set OC to be the same language as the OS (rather than the same language as Office, if the OS and Office are in different languages) to ensure that OC and LM always end up being in the same language.

IV.    Outlook Add-In for Conferencing – Language & Localisation Settings

The Outlook Add-In for Conference Scheduling will automatically change to the default language that Office is configured to use.   We didn’t test all 37 of the supported Office languages to see if the add-in  supports all of them, but it did support the western and non-western languages that we tried.

V.  Previous Versions

For completeness, I’m including the languages supported by previous versions of the the clients, which is a subset of the languages supported in the current 2007 versions.

• Office Communicator 2005 supported the following 12 languages (in addition to English) via a MUI Pack:  Spanish, Korean, Japanese, Italian, German, French, Chinese – Traditional, Chinese – Simplified, Danish, Finnish, Portuguese (Brazil), Swedish
• The Office Live Meeting 2005 client supported the following 7 languages (no MUI Pack required): French, German, Spanish, English, Korean, Japanese, Chinese – Simplified
• The Office Live Meeting 2003 client supported only English. 

-John Lamb, Modality Systems

Technorati Tags: Office Communicator, Live Meeting, Software Localization

When I joined Modality I thought my days of hopping on planes and travelling around Europe would be numbered.  (My last role was at Microsoft as a Rapid Response Engineer and this included excessive travel).  Little did I know that Troy Zaboukos, Senior Unified Communications Product Manager for Central & Eastern Europe Microsoft was planning  to launch the OCS Ignite Roadshow throughout Eastern Europe and that I would be the presenter

The Ignite tour looked like this..

Location	Course Delivery	City
Latvia	Oct. 3-4	Riga
Hungary	Oct. 17-18	Budapest
Kazakhstan	Oct. 23-24	Almaty
Lithuania	Oct. 25-26	Vilnius
Czech Republic	Oct. 30-31	Prague
Croatia	Nov. 8-9	Zagrab
Greece	Nov. 13-14	Athens
Slovenia	Nov 27-28	Ljubljana
Ukraine	Jan 24-25	Kiev

. 

I was fortunate enough to present all but two of the Ignite Roadshows.  My colleague Paul Duffy presented in Kazakhstan and a local presenter assisted in the Czech Republic.  I would like to take this opportunity to thank all the attendee’s for taking time out to attend the sessions and provide such excellent feedback, which will assist in future events. 

What’s next I hear you ask? Well due to the success of OCS Ignite, a new OCS Voice Ignite is in the pipeline.   We attended the Voice Ignite training in Barcelona the week of 16th of Jan.  This time around its 5 days of hardcore OCS / Voice integration and is pitched at level 300 / 400, which should be great.   

Watch this blog for tour dates and more news coming soon. 

- Mike Warren, Modality Systems

This has to be the most frequent question that I get asked:  "Is there a good book on OCS?"

The answer is "Yes" and I’m thrilled that the book is now available on Amazon and other online book sellers in both the US and UK.

Microsoft Office Communications Server 2007 Resource Kit by Jeremy Buch, Jochen Kunert and Rui Maximo   MS Press Official Site    Amazon UK Link    Amazon.com Link

I had the enviable opportunity to contribute to the book as a technical review and sidebar author.  I accepted the role because I worked with all 3 authors (Rui Maximo, Jeremy Buch, and Jochen Kunert) when I was in the UC product group in Redmond.  They are literally among the top talent in the UC team and  when I heard they were collaborating on an MS Press book, it sounded too good to be true.  But… its true and it is that good.  

You don’t have to take my word for it.  A few sample chapters are available on the Microsoft web site, which you can download from here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=407a3e40-350a-4e3d-b60e-c9505668b231&displaylang=en

The preview chapters are uncorrected manuscript, for early preview, and may have changed before the book went to press.  The 3 preview chapters available to download are:

• Chapter 3: Infrastructure and Security Considerations
• Chapter 4: Basic IM and Presence Scenario
• Chapter 9: Remote Call Control Scenario

Feel free to post any feedback on the book in the comments section.   We’re ordering a bunch and will be handing them out to our clients.

-John Lamb, Modality Systems