Core OS

I know it is a work in progress but I believe that this hotfix will end up being a pre-req for installing on Server 2008 R2.

KB 975858 - An application or service that calls the InitializeSecurityContext function together with the ISC_REQ_EXTENDED_ERROR flag may encounter a TLS/SSL negotiation failure on a computer that is running Windows Server 2008 R2 or Windows 7

Specifically due to this section of the article:
For example, a Transport Layer Security (TLS) negotiation fails when Microsoft Office Communicator Server 2007 R2 is installed on a computer that is running Windows Server 2008 R2. This problem causes some functions not to work in Office Communicator Server 2007 R2.

These type of blog entries were always popular in the Windows XP and Windows Vista time frame. You'll notice that this list is smaller than the Vista post-RTM / pre-SP1 list I made a few years ago. It isn't a coincidence. There were some major overhauls and redesigns in the Vista time frame.

Despite what the press might have said, and what users experienced during the early days of buggy Vista drivers, the end results have been mostly worth it. You see Windows 7 getting "rooted" must less often than XP, and the same can be said for malware especially if you leave UAC enabled. I tend to restart my laptop only when security updates come out, otherwise I put it to sleep or hibernate. Some of these fixes listed below are related to sleep and hibernation issues and have definitely helped me.

Keep in mind, if you aren't having issues with the items below, you can safely skip installing these. Many of these are corner cases or uncommon scenarios, but I happen to hit a few of them.

Core OS
KB 977346 - The Welcome screen may be displayed for 30 seconds during the logon process after you set a solid color as the desktop background in Windows 7 or in Windows Server 2008 R2

KB 977542 - A hotfix is available to block standard users from logging on to a Window 7-based or Windows Server 2008 R2-based computer in safe mode

KB 976746 - Error message when a Windows Server 2008 R2-based or a Windows 7-based computer enters hibernation: "STOP: 0x0000000A"

KB 975992 - After you enable large pages for a process in Windows 7 or in Windows Server 2008 R2, the process stops responding intermittently

KB 975680 - Virtual Disk Service (VDS) crashes when you try to extend a dynamic volume in an NTFS file system on a computer that is running Windows Vista, Windows Server 2008, Windows Server 2008 R2, or Windows 7

IDE/SATA/Firewire
KB 976418 - After you change the SATA mode of disk devices to use the AHCI specification, the computer or certain applications randomly stop responding for 60 seconds or for longer in Windows 7 and in Windows Server 2008 R2

KB 977178 (newer than KB 976418) - You receive various Stop error messages in Windows 7 or in Windows Server 2008 R2 when you try to resume a computer that has a large SATA hard disk

KB 975500 - Low performance when you transfer a large file between an external IEEE 1394 device and a computer that is running Windows 7 or Windows Server 2008 R2

KB 977186 - Error message when you try to resume a Windows 7-based or a Windows Server 2008 R2-based computer from hibernation: "Stop 0x0000009F"

Multimedia
KB 975538 - Audio devices are missing or are displayed as "Not plugged in" after you restart a the computer that is running Windows 7 or Windows Server 2008 R2

KB 975450 - You may experience display corruption issues on certain Intel graphics processing unit (GPU) chipsets in Windows 7 (hardware bug - use driver 15.4.4 or higher)

KB 979303 - Audio playback and capture applications hang

KB 975806 - The video image flickers when you configure Windows Media Player 12 to display the subtitles of a DVD in Windows 7 or in Windows Server 2008 R2

KB 975617 - An update is available for the UDF file system driver (Udfs.sys) for Windows 7 and Windows Server 2008 R2

KB 976417 - High CPU usage in the Explorer.exe process when you open a folder that contains corrupted .wav files in Windows 7 or in Windows Server 2008 R2

Networking
KB 976658 - The memory of the nonpaged pool may leak when you enable IPsec on a computer that is running Windows Server 2008 R2 or Windows 7

KB 975851 - When you resume a computer that is running Windows 7, WWAN devices do not automatically connect to the target 3G network

KB 978869 - Error message when you try to open a network-shared application on a client computer that is running Windows 7 or Windows Server 2008 R2: 0xc000000f

USB
KB 978258 - USB devices that are connected to a computer may not work after the computer is idle for more than one hour Windows 7 or in Windows Server 2008 R2

KB 974476 - The computer stops responding when an USB device resumes from the USB Selective Suspend state in Windows 7 or in Windows Server 2008 R2

KB 975599 - Stop error when you put a computer that is running Windows 7 or Windows Server 2008 R2 to sleep or into hibernation, or when you restart the computer: "0x9F"

Virtual PC / Windows XP Mode
KB 977632 - A computer that is running a virtual machine in Windows Virtual PC may stop responding or restart when you resume it from sleep or from hibernation in Windows 7

This definitely the strangest bug I've ever encountered with Windows 7 but I have experienced it on numerous systems because on any system that I have control over, I typically set my background to black. No wallpaper. No pattern. Just black. I also do this on Windows 2008 R2.

I would typically hear some applications loading in my tray and "ding" me for UAC access to hardware, but would still be sitting at the Welcome screen.

I originally wrote it off as a fluke when it first happened but after installing the hot fix, there is a definitely a difference in behavior.

Consider the following scenario:

You have a computer that is running Windows 7 or Windows Server 2008 R2.
You set a solid color as the desktop background.
The Desktop Window Manager Session Manager service is running.
You log on to the computer locally.

In this scenario, the Welcome screen is displayed for 30 seconds during the logon process.

This issue does not occur when one or more of the following conditions are true:
You log on to the computer by using Remote Desktop Connection.
The Desktop Window Manager Session Manager service is stopped or is disabled.
You set an image file as the desktop background.

You can read about the issue and download the fix from here.

A few months ago I detailed about a problem with OCS services not starting after a reboot, a general loss of network connectivity during boot and the inability to RDP to those servers once this scenario was triggered.

I bumped into a new article from a Paul Adams at MS that has a handy PowerShell script to add in the workaround for the deadlock problem. It is also noted, just from general banter on the Internet, forums and newsgroups, that the OCS servers involved are typically HP servers that used the SmartStart CD/DVD for installation. It could be that HP agents, drivers or services added to the base OS are causing this issue to flare up. Any OCS servers I have seen, so far, that had this problem were HP servers.

The PowerShell script can be downloaded from here, and it refers to an earlier post by the same author detailing the technical reasons as to why and how it can happen. Ideally, I'm hoping a more generic/official fix for it becomes available from Microsoft at some point for the OS. OCS unfortunately is just a possible trigger for this issue, and the issue comes from the underlying operating system.

Update: In a weird twist of fate, this issue/bug does not exist with Server 2008 R2, but OCS 2007 R2 isn't supported under Server 2008 R2 yet.

I used to subscribe to product specific RSS feeds to catch new cumulative updates for Office but now there is a dedicated site inside TechNet which makes this practice redundant.

Go here to check out service packs and cumulative updates for Office, Forms Server, Groove Server, PerformancePoint Server, Project Portfolio Server, Project Server, Search Server, SharePoint Server, and Windows SharePoint Services. Very handy to bookmark.

In July 2007, I was originally awarded Microsoft MVP for Windows User/Shell. This area tended to confuse people because they thought it was related to batch files or PowerShell.

In the following months, I was nominated for Forefront MVP and OCS MVP. Both were very flattering because it meant I was getting attention from Microsoft from multiple sources. At the time, I had no idea you could have a 'primary' competency and a few secondaries. OCS and Forefront ended up as my secondary competencies.

2007 and 2008 were very busy years for this blog and for myself. Mostly positive, and I enjoyed what I was doing.

Thankfully, in July 2008, I was re-awarded the MVP and the category changed from Windows User/Shell to Windows Desktop Experience. This confused people much less and I was honored to be chosen again.

Midway through that MVP year, I was invited into the newly formed Windows Systems and Performance MVP group. It was a smaller group of MVPs and more in line with the topics I had been covering during that time. A great match, and I was able to keep my same MVP lead.

At the end of 2008, my work had a reorganization and I changed from being just a Microsoft Consultant to a Microsoft Unified Communications Consultant. This meant my day to day work life would revolve around Exchange 2010 and OCS 2007 R2 for the most part. Thankfully, I've been doing Exchange since version 5.5 and OCS since it was called LCS 2005, in beta.

Overall, this meant this blog would slightly shift focus as I worked specifically on UC projects.

In July 2009, I was re-awarded the MVP for Windows Systems and Performance.

After a lot of thought and consideration, I recently asked to be moved from the Windows Systems and Performance MVP group over to the OCS MVP group.

I'm happy to announce that they approved the move and now, I'm in my 3rd MVP category in 3 years, Office Communications Server.

In general, that doesn't mean I am going to leave the other aspects I've traditionally covered or gave speeches about, including Windows 2008 R2, Windows 7, Exchange 2010 and anything else that captures my attention.

Overall, I'm just excited to be in this MVP group as it aligns with my work environment.

At some point, I want to go for the OCS MCM (Microsoft Certified Master).

I have come across this situation a few times now out in the field so I thought it might be a good time to describe the problem and some easy ways to mitigate or avoid the issue. The January 2010 OCS Server updates related to NTLM reminded me about this issue.

It is pretty common place to lock down, with a GPO or registry setting, the NTLM settings on member servers, domain controllers and client computers. Although uncommon, there are scenarios where you can effectively break any NTLM negotiation between domain controllers, member servers and clients.

Thankfully, these are well documented in KB 823659, “Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments”.

Consider this scenario:

OCS servers and internal network (local LAN) clients are Active Directory domain joined.
Non-domain joined clients connect through an OCS Edge.

If NTLMMINCLIENTSEC and/or NTLMMINSERVERSEC differ between clients and servers, for the internal clients and servers, Kerberos authentication will still be functional, assuming you haven't set the pool to only accept NTLM.

Clients that connect through the Edge will be rely entirely on NTLM because Kerberos is not available as an authentication method, as noted in the excellent OCS 2007 R2 Resource Kit.

If NTLM is “broken” inside the domain between domain controllers and OCS servers (front End/edge), the Office Communicator client will act as if the user entered an invalid username or password. The error message on the client computer is very misleading and everyone external will not be able to log in.

As noted in TechNet here, OCS is very particular about the NTLMv2 settings.

These settings, for server and client, can be set in a group policy under Network security: Minimum session security for NTLM SSP based (including secure RPC), or by use of a registry setting.

To directly quote Technet:
Sometimes the server will be configured to require encryption, and the client will not. In this case, the client NTLM request is not passed on by the front-end server. This situation primarily affects external users, because NTLM is the only authentication protocol that external clients can use to sign in. For example, if the server key is configured to have a value of 0x20080030, which specifies 128-bit encryption, and clients are not, clients will be unable to sign in. You should ensure that this key on the client is configured to match the server’s setting.

As operating systems have evolved, the default security settings for NTLMMINCLIENTSEC and NTLMMINSERVERSEC have been changed, which is a good thing.

By default, anything older than Windows 7 and Server 2008 R2, these registry settings will be configured to not require 128-bit encryption and not require NTLMv2 session security.

Windows 7 and Server 2008 R2 require 128-bit encryption by default, only.

As Microsoft de-emphasizes NTLM in favor of Kerberos and other plug-in authentication methods, you most likely will want to raise the minimum for NTLM for everyone as legacy operating systems are retired from your environment.

You might even want to follow the Server 2008 Security Guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e) when setting up your policies, which specifies requiring 128-bit encryption and NTLMv2 session security.

In a misconfigured environment, the packets going back and forth between the OCS Edge and OCS Front End will look normal except that the NTLM negotiations will always fail.

The obvious fix is to make sure you have these settings consistent across your organization to begin with and you will never see this problem. It can be problematic if you configure all the servers without configuring all clients with identical settings because clients will be unable to connect to your OCS servers through the Edge without modifying their default operating system settings.

In particular, if you have an unmanaged client environment outside of the office (a very common scenario), you might want to provide the following registry file as a way to help secure your environment and enable unmanaged clients to connect:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"NtlmMinClientSec"=dword:20080000
"NtlmMinServerSec"=dword:20080000

Those registry settings above are equivalent to configuring the following group policy with these options, for client and server:




On a somewhat related note, since we are touching upon NTLM, one of the best tutorials about NTLM gotchas appeared in the August 2006 Security Watch article by Jesper Johansson.

In particular, pay attention to the section detailing the specifics of LMCompatibilityLevel.

In group policy, LMCompatibilityLevel, has a description that looks promising as a potential “most compatible secure” setting but does not behave like the description might lead you to believe.

If you set LMCompatibilityLevel to 1 (Send LM and NTLM – use NTLMv2 session security if negotiated), LM, NTLM and NTLMv2 will be accepted but NTLMv2 will never be sent from the client.

Using 1 might look appealing in a debugging scenario but I would use LMCompatibilityLevel set to 5 to eliminate use of the LM and NTLMv1 protocols.

The gory details are best explained in the above mentioned Security Watch article.

Overall, assuming all your software and operating systems on your network work properly with NTLMv2, I recommend using the recommendations from the Server 2008 Security Guide and setting NTLMMINCLIENTSEC and NTLMMINSERVERSEC to 0x20080000 for all servers and clients. You’ll avoid the OCS Edge headache and you will help avoid older l0phtcrack attacks.

Windows 7 and Server 2008 R2 add some handy NTLM auditing policies that can be used to restrict NTLM but also audit NTLM usage. You can configure the restrictions in audit only mode to see what servers and clients are using NTLM for authentication. It can be handy as a debugging tool and I used it originally when I initially ran into this issue. A good writeup about this can be found here on the Microsoft site. Using these new tools, you might be find applications you never knew that were using NTLM and potentially verify that you can enable NTLMv2 only everywhere.

This update (KB 976135) contains the following fixes:

KB 978161 - Office Communicator 2007 R2 crashes when you receive an incoming instant message notification

KB 978162 - A hyperlink is converted to plain text format when you input the hyperlink into an Office Communicator 2007 R2 conversation window

KB 978163 - You cannot call a user by using the Actions button in Office Outlook 2007, but you can call the user through Office Communicator 2007 R2

You can download the update here.

I'm not sure if this client update addresses the compact delta GAL/stale GAL problem mentioned here yet or not.

Update: I had the version wrong in the title originally and a few new discoveries have surfaced. This version has the proper 64-bit MAPI/EWS/API support for 64-bit Office 2010, which means that Outlook integration (missed call notification, voice mail notification, "In a meeting" status) works for people brave enough (like me) to go completely 64-bit with Office 2010.

Also of note, which might be a side effect of the new 64-bit support, the client is now reporting "x64" instead of "x32" to the OCS Client Filter, as already noted numerous places. Read more about it here and here. For now, it is best just to duplicate your "x32" directory structure as "x64" until a "real" x64 client is available with patches or further guidance is provided from MS. I'm going to update my Client Filter post to reflect this shortly too.

Not a lot of changes, server side for OCS 2007 R2 in these updates but a few that have been longstanding annoyances. On a plus note, these updates remove the need for applying the OCS ASN fix caused by KB 974571 (MS09-056).

For the overall list of server updates and update guidance, check out KB 968802.

If you look over the list at the KB article above, you'll notice that only certain components were updated for January 2010:

Administration Tools (AdminTools.msp) and Core Components (Ocscore.msp):

KB 978371 - An offline certificate request is formatted incorrectly when you create the certificate request in Office Communications Server 2007 R2 on a computer that is running Windows Server 2008

This fix is particularly welcome because the certificate request output varied depending on if the server used Server 2003 or Server 2008. Some certificate authorities require -----BEGIN CERTIFICATE REQUEST----- at the beginning of the certificate request and -----END CERTIFICATE REQUEST----- at the end.

Server (Server.msp):

KB 978363 - You experience performance issues in Office Communications Server 2007 R2 during NTLM authentication

KB 978364 - You experience performance issues in Office Communications Server 2007 R2 when you move many users between pools at the same time

KB 978366 - Instant messages are blocked in Office Communications Server 2007 R2 if a third-party application uses the "otherIpPhone" attribute

KB 978367 - You cannot start the Office Communications Server 2007 R2 Front-End service if the connection to the root domain controller is lost

KB 978369 - Instant messaging fails when the Office Communications Server 2007 R2 front-end server that you connect to changes

Database (OCS2007-DBUpgrade.msi):

Not installed by ServerUpdateInstaller.exe - must be installed manually with all the other updates if you want proper operation.

The link to the Download Center seems invalid at the moment but the Request Hotfix link works.

KB 978362 - You experience performance issues in Office Communications Server 2007 R2 when many legacy presence users are converted to enhanced presence users at the same time

Unified Communications Managed API 2.0 Core Redist 64-bit:

KB 978372 - CPU usage increases when you turn on tracing for the S4 component in Office Communications Server 2007 R2

As always, the easiest method of installing the updates is to use the ServerUpdateInstaller.exe, combined with the manual application of the database update.