Certifications
Categories
RSS
Wednesday, April 29. 2009
RtcQmsAgent fails to start on OCS 2007 R2 server - and causes KB 967831 (April 2009 update for Front End Server components) install to fail
Tuesday, April 28. 2009
Outlook 2007 improvements in SP2 - and Office 2007 SP2 download link - almost live as of 2am EST
Tuesday, April 21. 2009
Demystifying the Office Communicator 2007 R2 Client Auto-Update feature and how to setup it up
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.
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.
Monday, April 20. 2009
Exchange 2010 Beta - "The WS-Management service cannot process the request"
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."
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."
Wednesday, April 15. 2009
Exchange 2010 TechNet Forums are live!
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. 
Tuesday, April 14. 2009
Edge Planning Tool for Office Communications Server 2007 R2
Microsoft Exchange Server 2010 Beta - build 14.00.0482.020 - download link
Here comes Exchange 2010 - public beta tomorrow! (US Tax Day - April 15th)
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!
E14 the world!
Monday, April 13. 2009
Office Communications Server 2007 R2 updates - April 2, 2009
Sunday, April 12. 2009
Outlook Thread Compressor - saved 100MB of redundant e-mail for me! Use with care!
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.
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.
Friday, April 10. 2009
Microsoft Unified Communications Virtual User Group (UCVUG)
Office Communicator 2007 R2 - April 2009 hotfix rollup - v3.5.6907.9
Thursday, April 9. 2009
OCS 2007 R2 .chm documentation finally available!
Saturday, April 4. 2009
OCS 2007 R2 AOL PIC issue workaround
Search this blog
Links
My e-mail address
Exchange:
Hotfix Tracker (All products)
OCS:
OCS 2007 R2 Documentation Collection
Office:
Office Cumulative Updates Site
Windows:
Other:
