Unified Comm

If you are not planning on using the Office Communications Server Monitoring Agent, which is fairly common assumption in lab environments, you likely never planned on installing MSMQ or knew that you had to. Unfortunately, the OCS 2007 R2 setup program does not check to see if MSMQ is installed, and assumes that it always needs to start up the RtcQmsAgent (Monitoring Agent) service on Front End servers. Unfortunately, if you do not install MSMQ, the service will never start up and will trigger service errors. Elan ran into this issue in his install tutorial for OCS 2007 R2.

It doesn't impede normal operation, assuming you are not using parts of OCS that rely on MSMQ (Archival/etc), until you attempt to install the April 2009 OCS 2007 R2 updates (QFE1).

In particular, KB 967831, will attempt to shut down the services to patch, install the new files and then attempt to start up all the updated services. Due to MSMQ missing, it will encounter a service failure and attempt to revert the patch.

On a bad note, this leaves your OCS Front End install with partial QFE1 (April 2009 - .9) files and RTM (Dec 2008 - .0) files. Even worse, the services will not start up even if you revert the other QFE1 updates for the Front End server.

On a good note, you can install MSMQ to get around the unfortunate "server killer" situation.

With Server 2008, you can run ServerManagerCmd -i MSMQ-Services and ServerManagerCmd -i MSMQ-Server.
With Server 2003 x64, it is a little more complex as an automation task but can be done using the details mentioned here.

The RtcQmsAgent service will no longer fail to start. At that point, you should be able to install all of the QFE1 updates successfully.

Also noteworthy, it is very important to pay attention to which updates are needed for which servers because these updates still don't seem to be on Microsoft Update and have to be requested individually. The KB article here details which updates are needed by which OCS server roles. Don't mix and match releases or else you might end up with unstartable OCS services.

Found the soon-to-be-active download link to Office 2007 SP2 while reading a KB article published here about performance improvements in Outlook 2007 SP2. It looks like this is in addition to the speed improvements seen in the Feb 2009 and late 2008 Outlook updates.

Too long to list here overall but a good read.

Following the release of the first Office Communicator 2007 R2 hotfix/update, which I wrote about here, I wondered exactly how to approve and install the release to the clients. The documentation surrounding this aspect has been hard to track down and vague at best. Even though there is a section specifically for Office Communicator client updates inside WSUS, it doesn't control the automated deployment of the updates.

Even though you might think the client update configuration would be buried inside the Device Updater portion of the OCS 2007 R2 server, the section you need to investigate is the Client Version Filter.

Depending on how your OCS environment is setup, you can either setup this filter at the Enterprise Edition pool level or at the Standard Edition server level. You can always test deployment on a Standard Edition server, and then later once you have verified that the update works properly, deploy it to your Enterprise Edition pool.



In the past, this section was primarily used to block older versions of software from connecting into the newer server pools. In OCS 2007 R2, this has been expanded upon to allow you to point users to a static URL page upon blocking, or better yet, offer up the updated client bits.

Because the recent update takes the OC version from 3.5.6907.0 to 3.5.6907.9, you'll want to add a version filter to match 3.5.6907.0. Select Allow and Upgrade as the action, and type in a directory name that makes sense for your organization. I tried to specify a multi-level directory, such as OC\3.5.6907.9\ and OC/3.5.6907.9/ in order to maintain version control inside the file share, but I could not get those to work properly. I relented and just used OC as the folder name.

Here is what the Client Version Filter editor looks like while you are setting up the new version entry:


Here is what the Client Version Filter editor looks like once you have set up the entry:


The Client Version Filter editor automatically filled out the directory structure as \\AutoUpdate\OC\x32\fre\1033. The fre relates to the licensing edition and the 1033 refers to the locale. I would have expected the use of x86 instead of x32, and I wasn't sure where \\AutoUpdate needed to be on the OCS server. After a bit of trial and error, here is what I figured out.

On a Standard Edition server, the location is %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files. The folder to place the communicator.msp file into is %ProgramFiles%\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\OC\x32\fre\1033\.

On an Enterprise Edition server, the location is inside the file share you specified for Device Updates, for instance, \\OCS-EE-POOL\Updates. Assuming your Device Updates file share is located at C:\OCS\Updates\, the folder to place the communicator.msp file into would be C:\OCS\Updates\OC\x32\fre\1033\, which in theory maps to \\OCS-EE-POOL\Updates\OC\x32\fre\1033\communicator.msp.

Why do I say in theory? Originally, I could not get the Enterprise Edition to work as expected. The IIS request that comes in from the Office Communicator client when it tries to request an update looks something like this:
POST /AutoUpdate/Ext/Handler/OCUpgrade.aspx folder=OC&lang=1033&mode=non-ui&arch=x32&flavor=pm&build=fre

The Office Communicator clients were receiving a 401 error and not even attempting to authenticate to the server. After digging through IIS failed trace logs, I figured out that the IIS code was trying to contact the file share as the Enterprise Edition pool name (\\OCS-EE-POOL\Updates) and not the server name of the Front End server (\\OCS-FE1\Updates). Browsing from the Run dialog box on the front end server, I could get to \\OCS-FE1\Updates\file share path just fine, but I could not resolve or get to \\OCS-EE-POOL\Updates\.

After thinking about it a while, it made sense to me. There isn't a file share resource registered anywhere in Active Directory with the OCS EE pool name, because there isn't a clustered file share involved or an actual server registered as OCS-EE-POOL.

Although there probably is a better solution than this, I ended up registering cifs/OCS-EE-POOL and cifs/OCS-EE-POOL.contoso.com as additional SPNs for the computer object of the Front End server (OCS-FE1). You can do this using SETSPN or using ADSIEdit. If you're looking for a good example of how to do this, check out this blog post related to Communicator Web Access here. Make sure to remember to register the entries as cifs/ and not http/ on the Front End server's computer account. I'm only using that blog entry as a reference on how to add a SPN entry with ADSIEdit.

As soon as I did that, I could access the file using the EE pool name like how the AutoUpdate code tries to do. The HTTP 401 errors went away and the internal clients could download the update successfully.

With that accomplished, I attempted to update an Office Communicator client connected to the Internet and not the office network. I only saw Address Book Service requests coming into the Front End server. After a few minutes, I remembered that I had not updated our ISA reverse proxy to accept /AutoUpdate/ requests. /AutoUpdate/ did not exist until OCS 2007 R2 and should be added to your ISA configuration if you are updating from OCS 2007 R1.



Once that configuration change was in place, external clients were able to update to 3.5.6907.9. Even computers that were not joined to the domain updated correctly. The mystery had been solved!

Some additional debugging/troubleshooting tips:

The telltale sign that you have set up the updates correctly is that your IIS logs on the Front End server should start showing BITS requests for /AutoUpdate/Int/Files/OC/x32/fre/1033/communicator.msp and /AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp and have a HTTP status code of 206 and not 401.

Your internal clients will use the /Int/ URL and external clients will use the /Ext/ URL.

You can also "fake" requests from a web browser by requesting the same path. Assuming your reverse proxy server was published to https://owc.contoso.com, you could simply request https://owc.contoso.com/AutoUpdate/Ext/Files/OC/x32/fre/1033/communicator.msp and be able to download that file.

On a client computer that is in the process of downloading the update after Office Communicator launches, you can check the status that computer by running bitsadmin /list, assuming the client is Vista SP1 or higher.



Using a trick gleamed from this blog entry here, you can also check to see if an Auto-Update has been offered and the overall status of that update. Much like the Outlook [Ctrl]-Right-Click tray icon trick, you can press [Ctrl] on your keyboard and right click on the Communicator icon in your system tray to access an additional option called Configuration Information... This is a brand new option in Office Communicator 2007 R2, but offers some great debugging information for problematic client computers.



With all of this information, hopefully this clears up some of the confusion over Office Communicator 2007 R2 Client Auto-Updates!

I wouldn't have been able to figure all of this out without the help of John Fedor! Many thanks again!

Update: Corrected "HOST" SPN to "cifs" SPN, thanks to Robert Lacroix! Also, I have since found out that there is a tool inside the Office Communications Server 2007 R2 Resource Kit that will automatically setup the file paths for you inside the updates folder - CvcMsiUploader.

If you haven't figured out by now, Exchange 2010 makes extensive use of PowerShell 2.0 and WinRM/WinRS to execute scripts and management tools. On a good note, this simplifies (in theory and so far, in practice) firewall exceptions/rules that need to be made for remote management of Exchange 2010 servers.

If you are like me, and tend to open multiple Exchange Management Consoles and/or remote PowerShell instances, it is very easy to hit the default limits set on Windows Server 2008 for WinRS/WinRM (based on the WS-Management standard).

A common error dialog that will pop once you hit this limit says:

"Connecting to remote server failed with the following error message : The WS-Management service cannot process the request. This user is allowed a maximum number of 4 concurrent shells, which has been exceeded. Close existing shells or raise the quota for this user."



For most applications, the defaults are fine, but if you want to enable more connections, it is just a matter of setting a few WinRM settings for remote shells (WinRM).

To check what the current WinRM/WinRS settings, run this from an administrative command line:
winrm get winrm/config/winrs

The output should look something like this:

AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 5
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 5

To raise the limits a little bit, run the following commands:
winrm set winrm/config/winrs @{MaxShellsPerUser="25"}
winrm set winrm/config/winrs @{MaxConcurrentUsers="25"}

The output should now look like this:

AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 25
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 25

Unless your server is undersized, these should be fairly sane limits.

All of this info is based off of Exchange 2010 Beta and WinRM 2.0 CTP3

Update: Well, that is a good method of raising the limits for WinRS, but it won't affect Exchange's limits. The proper, and much easier way, of achieving this goal is simply a matter of running this Powershell cmdlet:
Get-ThrottlingPolicy | Set-ThrottlingPolicy -powershellmaxconcurrency 25

Thanks go out to Robbie Roberts for the insight into this.

Update #2: So, the method in Update #1 is a little bit ham-fisted as pointed out by David Sterling from Microsoft.

"Be very careful about this. The Get-ThrottlingPolicy | Set-ThrottlingPolicy syntax will result in ALL throttling policies in the org being given the ability to have 25 open runspaces. If you really just want a single individual to have more headroom for this kind of stuff, the best way to accomplish this is to create a new throttling policy via New-ThrottlingPolicy and simply override the PowerShellMaxConcurrency parameter. Then explicitly assign that policy to the user in quesiton via Set-Mailbox "Foo" -ThrottlingPolicy $newPolicy."

Do you have a DAG IP address assignment question that has you stumped? Having trouble configuring the new built-in MWI options? Arbitration mailbox uninstall giving you the blues? Ask your questions over at the Exchange 2010 forums here. You might see me posting there from time to time too.

The Edge Planning Tool asks questions about your proposed or current edge server deployment. The tool uses your answers and Microsoft Office Communications Server 2007 R2 best practices to generate the following reports:

Settings that you can use to configure your certificates, DNS services, and firewalls
Custom documentation for configuring your edge servers, reverse proxy, and next hop server
A comparison of your answers to Microsoft Office Communications Server 2007 R2 best practices

Download it from here.

Also don't forget to check out the Office Communications Server 2007 R2 Capacity Planning Tool, recently released too.

Well that didn't take long! You can download the beta here.

Want to know what is new in Exchange 2010? Go here.

This time-limited, free beta version of Microsoft® Exchange Server 2010 will end 360 days after installation.

Also available:
Exchange Server 2010 Beta UM Language Packs

As noted here at PC World, Exchange 2010 Public Beta will be available for download on US Tax Day if all things go as planned.

E14 the world!

To go along with the Office Communicator 2007 R2 April update mentioned here, we have a server side update that brings the build to v3.5.6907.9.

Most of them seem to involve certificates, Response Group, and the Conferencing Attendant related. The Conferencing Attendant issue listed below has been particularly annoying for some users, so I'm glad to see it listed.

KB 967832 - Application Host

When you configure the Communications Server 2007 SIP Proxy to listen on a port other than the default SIP TLS port, SIP connections cannot be initiated by Response Group Server or by Conference Auto Attendant

KB 967833 - Application Sharing Server

When you try to import configuration settings into Communications Server 2007 R2, the Application Sharing multipoint control unit does not register the new media relay for the pool

KB 968280 - Administration Tools

Response Group Service cannot start if you assign a certificate that has a wildcard in the Subject Name to Office Communications Server 2007 R2

Response Group Service cannot start if you assign a certificate that contains a SAN list, and the last name on the list is not the pool FQDN to Office Communications Server 2007 R2

After you restart the Communications Server 2007 R2 Response Group Service, the service does not send calls to agents

The Communications Server 2007 R2 Response Group Service does not update its list of trusted hosts at run time

KB 967827 - Core Components

Error message when you open an audit log file for Office Communications Server 2007 R2: "The process cannot access the log file because is being used any another process"

KB 967836 - Communicator Web Access

The Office Communications Server 2007 R2 Dial-in Conferencing Settings page will not display the user's conference ID when the global meeting policy is set to disallow anonymous users

When a Communications Server (OCS) 2007 user clicks an OCS 2007 R2 audio conference join link, the user receives an incorrect error message

A Communicator Web Access user who joins a conference as a federated user cannot share the computer desktop in Office Communications Server 2007 R2

When a user uses Office Communicator (OC) or Communicator Web Access (CWA) to send an IM message to a federated or Public IM Connectivity user, OC or CWA may give an incorrect notification of the IM delivery status

The selected language is not used when a user on a localized version of Communications Server 2007 R2 signs in to the dial-in conferencing page by using Integrated Windows Authentication and then selects a language from the drop-down list

The logo at the top of the Communications Server 2007 R2 Dial-in Conferencing Settings page is only in English, even after the Communicator Web Access language pack is installed

Users who have special characters in their names cannot sign in to the Office Communications Server 2007 R2 Dial-in Conferencing Settings page

KB 968913 - Conferencing Attendant

Enterprise users can have a conference call without the Presenter/Leader and without realizing that Public Switched Telephone Network (PSTN) users are on hold in Communications Server 2007 R2

KB 967837 - Monitoring Server

Communication Monitoring Server 2007 R2 cannot support more than 100 instances of Mediation Server or of A/V Conferencing Server

KB 967675 - Mediation Server

Fixes not listed yet on Microsoft's site.

KB 967835 - Outside Voice Control

The Outside Voice Control service rejects connections from a new server as non-trusted connections in a Communications Server 2007 R2 deployment

KB 967829 - Response Group Service

Response Group Service cannot start if you assign a certificate that has a wildcard in the Subject Name to Communications Server 2007 R2

Response Group Service cannot start if you assign a certificate that contains a subject alternate names (SAN) list, and the last name is not the pool FQDN to Office Communications Server 2007 R2

After you restart the Communications Server 2007 R2 Response Group Service, the service does not send calls to agents

The Communications Server 2007 R2 Response Group Service does not update its list of trusted hosts at run time

KB 967831 - Enterprise Edition Server

You cannot forward a call between federated users in Communications Server 2007 R2

Communications Server 2007 R2 - A/V Edge Authentication Server does not recognize a token request if the locale for RTCProxyService is not en-US/409

Communications Server 2007 R2 does not detect the changes when Unified Messaging dial plans or UM servers are added

KB 967674 - Unified Communications Manager API 2.0 Core Redist 64-bit

Fixes not listed yet on Microsoft's site.

KB 967830 - Web Components Server

Error message when you open an audit log file for Communications Server 2007 R2: "The process cannot access the log file because is being used any another process"

Response Group Service cannot start if you assign a certificate that has a wildcard in the Subject Name to Communications Server 2007 R2

After you restart the Communications Server 2007 R2 Response Group Service, the service does not send calls to agents

The Communications Server 2007 R2 Response Group Service does not update its list of trusted hosts at run time

You can read about the complete list of fixes here.

The easiest way to get these updates on to your server(s) is to use Microsoft Update, and update all servers so that there is isn't a mix of v3.5.6907.0 servers and v3.5.6907.9 servers.

This tool originally was a long fabled internal Microsoft tool that finally has a somewhat proper "official" release to the web with plenty of warnings and caveats. It is an add-in for Outlook 2000/XP/2003/2007 which removes unnecessary emails, on the assumption that most people reply to mail and leave the original intact, so you could keep the last mail in each branch of a thread, and remove all the others. You would be surprised how often this happens!

It reduced the size of my Outlook mailbox by almost 1/5th tonight. Down to nearly 400MB from the original 500MB size.

Keep in mind - this program can and will delete e-mail content!
If you're in any doubt about this, then do not use this add-in.



You can download the add-in from here and read more about it. The installation instructions might seem a little daunting, and it can act a little quirky on initial launch, but it is definitely worth running from time to time.

Original description rom the website with some history behind the plug-in:
Thread Compressor is an add-in to Microsoft Outlook, which removed unnecessary emails from a "thread" - reducing the amount of storage required (maybe keeping your mailbox within its size quota) and reducing the number of emails you need to read.

TC was developed inside Microsoft from 1999 onwards, and attracted a large following (up to 30,000 users) but has never (officially) been made available externally, due to the fact that it will delete data unless it is configured not to. I've decided to share it more widely now.

Originally spotted here.

The Microsoft Unified Communications Virtual User Group (UCVUG) will be hosting it's first meeting on May 21st, 2009 at 7:00 PM Eastern Time. This event will be broadcast online via Microsoft Live Meeting. Please register if you plan to attend so that we can get a count of how many attendees to plan for.

Agenda

- UCVUG Welcome - Dustin Hannifin
- New Features in Microsoft Office Communications Server 2007 R2 - Jeff Schertz
- Evangelyze SmartSIP Solution (Connect OCS to standard SIP phones and almost any ITSP)- Mike Stacy
- Prize Drawing and Closing

Prizes

We will have a random drawing for the following prizes:
1 - Microsoft Office Communications Server 2007 R2 Resource Kit
1 - Microsoft LifeCam Webcam
1 - Microsoft Xbox Title TBD
To be eligible you must sign up for a free membership on the ucvug website and logged onto the live meeting during the drawing.

Meeting announcement and invite
UCVUG site
Outlook Calendar (.ICS) file for the kick off meeting

Issues fixed:

Communicator 2007 R2 update for Microsoft Online Services

You experience one-way audio when LG-Nortel IP8540 or Polycom CX700 phones are used in an Audio Video call on Windows XP

Error events occur when you disconnect a computer that is running Communicator 2007 R2 from the network: "Event ID: 3" or "Event ID: 7"

Initial changes for the integration of Office Communicator 2007 R2 and the next version of Office after the Office 2007 release

Communicator 2007 R2 stores the Actual Remote Number (The number that is dialed) for outgoing calls to a remote party

You cannot see features in Office 14 builds if you are running Communicator 2007 R2 RTM or earlier versions

The font in the Conversation window is very small when you run Office Communicator 2007 R2 on a Windows Vista-based computer that has high DPI (120 DPI) with Internet Explorer 8 installed

You cannot click the password field and enter a password when you sign in to Office Communicator 2007 R2

Office Communicator 2007 R2 update to support Polycom roundtable devices

In Office Communicator 2007 R2, User A gets a failure-to-deliver message after sending an IM to User B even though User B receives the message.

You can read more about the issues fixed in this release here.

Download the Office Communicator 2007 R2 client update here.

The update changes the build number from v3.5.6907.0 to v3.5.6907.9, which can be tracked inside the OCS 2007 R2 administration panel, under 'Database'.

Now for the $1000 question: How the heck do I install this update onto my OCS server so that my clients will automagically download the update when they connect in the next time? I cannot find how to configure the Office Communicator 2007 R2 Automatic Client Update functionality anywhere on the Internet or in the official documentation. I admit, I've only searched for about a half hour, but it is extremely frustrating. I already have updating the Phone Editions working 100%.

Update: Thanks to this blog post and a few e-mails later - I have a solution to the $1000 question here.

If you want to learn OCS 2007 R2, or need a "go to" guide offline - download this .chm now!

I know those are strong words, but I find myself referring to this file anytime I have an obscure or esoteric OCS issue.

Thanks to the heads up from Elan.

Come to find out, the issue does not appear on Windows 2003 x64 servers but only Windows 2008 x64. This is due to the order of the ciphers offered. Not to steal the thunder of the Microsoft fellow that figured it out, check out the full solution here. I've tested it on our servers and the issue between OCS and AOL is 100% resolved using this method.