There are many Lync-specific fixes so if you are planning on deploying Lync and will have a coexistence period, I would install these on your OCS 2007 R2 server setup before installing Lync. This is only a personal opinion but it looks like it would avoid some known gotchas.

The phone edition reports 6907.222 instead of 6907.221 like the rest of the updated components. I suspect it was a last minute bug fix/issue check-in after the other builds.

Thank to Richard for pointing out there were new updates for Live Meeting and the Conferencing Add-in.

Sunday, November 21. 2010

Although it wasn't funny at the time, my original Verizon Novatel USB 720 adapter was stolen by raccoons that raided our chicken coop where the home wireless setup lived. They killed all the chickens but they also took the 3G modem because it had blinking lights.

That back story might seem extraneous but it relates to this blog entry. The replacement 3G adapter was a Novatel 760. The 720 never locked up. The 760 would about once a week or once a month depending on usage.

The telltale signs were a solid light on and even powering off the unit through the VZW software would not work. I eventually just got used to unplugging it and plugging it back in after a while. It effectively would go into a coma on any computer it was used on.

Recently, there were 2 firmware updates released inside of the VZW access software. You can grab the latest software and firmware update from here.

With the new firmware, I can no longer make the device lock up and it seems to have better receive sensitivity. Either way, I recommend anyone using this device to perform the firmware update.

Saturday, November 20. 2010

If you are migrating mailboxes from Groupwise to on-premise Exchange 2010 SP1, you will want to setup a throttling policy on Exchange 2010 SP1 that is almost identical to the typical throttling settings used for Blackberry and/or Cisco Unity.

I typically recommend not setting any of the throttling values to unlimited. This is a bit more restrictive than the suggestions made by the Blackberry and/or Cisco Unity settings.

The most important throttling value we need to increase for Quest's Groupwise Migrator is the RCAPercentTimeInAD. The telltale sign are throttling event logs on the Exchange server and see-saw network/cpu usage on the migration workstation. The Address Book service seems to receive quite a bit of traffic from the Groupwise migration tools due to user account look ups.

On most of my migrations, I ended up using a value of 200 for RCAPercentTimeInAD. I have yet to encounter a server that required value higher than 200.

Thankfully, you can apply this new policy on the user account that acts as the go-between Exchange and Groupwise. Typically, it is called something like GWMigrate.

Additionally, you can also apply this new policy on the migration workstation's computer account. Typically, it is called something like GWMigrateServer.

Using that server name and user name as an example, this is what you would execute with Powershell on the Exchange server:

Monday, May 31. 2010

I tend to run bleeding edge software everywhere and when I can, I run the most native applications I can. This is why I'm running Office 2010 x64 on my x64 laptop. Primary reason is that most of the annoying Office plugins I don't want do not have a x64 counterpart yet. This includes the annoying iPhone plugin that iTunes installs that can make Outlook stall/crash on exit. Bad plugins can cause bad behavior.

Of course, there isn't a lot of 'gee-whiz-wow' aspects of running Office 2010 x64 other than it being a native app and not going thru the WOW64 emulation. You also get some of the security protection features that are not available with x86 applications.

Anyway, if you are daring and want to feel like an Apple Mac users for a while (No working Flash support), grab one of the FireFox nightly builds here.

If the Tinderbox directory seems to be empty (sometimes the build process gets broken and stale files removed), you can always check the trunk builds for x64 here. The x64 installer can be found here at the trunk location and the zip can be found here at the trunk location. Many times, the .zip file is newer than the x64 installer version.

To be able to use the executables, you will need the Visual Studio Runtimes for x64 which you can download here.

What I did was take the zip file, unzip it into "%ProgramFiles%\Mozilla FireFox" (NOT "%ProgramFiles(x86)%\Mozilla FireFox", unblock the executable since it was downloaded from the internet (oh no!), and launched the application. It does seem to run relatively faster overall and use less memory but maybe that it due to the lack of Flash.

You can always check the jemalloc stats by pulling up "about:memory" and seeing just how bad something might be leaking.

With "about:config", add "gfx.font_rendering.directwrite.enabled" (boolean) and set this to 'True'. Add "mozilla.widget.render-mode" (integer) and set this to '6'.

A noteworthy Windows 7 hotfix related to Direct2d and DirectWrite can be downloaded from here. It seems to make behavior more consistent for applications outside of just Visual Studio 2010. I have personally been running this hotfix with Firefox with DirectWrite enabled for a long time now with no major issues.

After restarting Firefox, the fonts on the page and browser should be anti-aliased. Websites with large images should load faster, and any SVG examples should be much faster.

If you run into problems with Direct2d and DirectWrite, check out this thread here.

If you run into Add-On Manager problems, unrelated to 64-bit but with the new AOM framework, check out this thread here.

Wednesday, May 19. 2010

The redesign of the Office website at Microsoft has made a few of the older links related to download of the Live Meeting client and Conferencing Add-In invalid, as pointed out by Matt Wade and followers of his website.

The issue has been reported to Microsoft and will hopefully soon be resolved, and this blog entry will be removed from this site.

Wednesday, May 5. 2010

KB 978164 - A conversation window opens unexpectedly when you press ENTER in the Search box in Office Communicator 2007
KB 979145 - The Office Communicator 2007 user interface pops up for all users who log on to a terminal server that is running Windows Server 2008

I suspect the release is mainly for the terminal server update and maybe OCS v.Next support.

Tuesday, January 12. 2010

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”.

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.

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:

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.

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.

Tuesday, November 17. 2009

If you head over to the Adobe labs section, you can pick up the new beta version of Flash Player 10.1 for IE and non-IE browsers. While you are at it, if you have an ATI/AMD video card, pick up the new Catalyst 9.11 that add support for this feature in most newer card. What does this bring to the table? Lower CPU usage and potentially better battery life.

I do believe that there are also new NVidia and Intel video card drivers out or coming out shortly to add direct support for this feature. Pretty neat.

Thursday, April 9. 2009

This is a fascinating project from a technical standpoint. They are implementing missing API calls used by newer applications that are missing from Windows 98 and Windows ME. I know what you are thinking, why? Well, why not! Even though their numbers are dwindling, there are still some users that want to use new applications on the old platforms. I'm not going to question it - I just know they exist.

Saturday, January 17. 2009

Don't leave home with them. Many OEMs are still shipping the older 10.x and 11.x revisions of this software, and are known to have bluescreen issues and other bugs that should be avoided.

You can easily install these drivers into Windows 7 by using the compatibility mode setting of "Vista" on the installation executables, or by simply pointing Device Manager to the directory you extract the archive to.

Friday, December 26. 2008

You might run into this with a QIP-based DHCP as a backend with XP SP3 clients: Some DHCP Options are not recognized on a Windows XP SP3-based client computer when the DHCP server offer includes option 43. Install KB 953761.

Long story, short: Due to the addition of vendor specific options of the XP SP3 DHCP client request, relating to NAP, the code expects DHCP options to be returned in a certain order. When paired with a MS-based DHCP server, correct behavior is observed. If used with a different DHCP server that might reorder the DHCP reply, the original XP SP3 DHCP client code might not correctly set all DHCP settings.

There is a two page thread on the TechNet forums about this issue here.