Core OS

MDT 2008 Update 1 includes new capability for OEM preload scenarios, a revised System Center Operations Manager Management Pack, bug fixes, and revised documentation.

MDT 2008 Update 1 enables deployment of the following Microsoft products:
Windows Vista Business, Enterprise, and Ultimate (32 and 64 bit) RTM and SP1
Office Professional, Professional Plus, Enterprise, and Ultimate 2007
Windows Server 2008
Windows Server 2003 R2 (32 and 64 bit)
Windows XP Professional with Service Pack 2 and Service Pack 3 (32 and 64 bit) or Windows XP Tablet PC Edition

Download it here, and read more about the update here.

Consider the following situation: You have a bandwidth starved branch office that has been configured with Office Communicator 2007 and remote call control of a 3rd party phone system. You want the users to be able to make calls with the 3rd party phone system with OCS, but you don't want precious bandwidth eaten up by PC-to-PC calls with Office Communicator.

Normally, you would enable option '4' for the TelephonyMode in a GPO for Office Communicator, but there is only one problem. This option is currently broken, and this effectively kills remote call control (RCC) on the user's computer. For now, the best advice is to tell users "don't do that", but you know it will happen by accident or on purpose because the option to do PC-to-PC calls will still be available if you unset the TelephonyMode.

I am hoping this is fixed in the July 2008 update, or it is on the radar to be fixed in the next set of patches for Office Communicator. It would be even better if Microsoft does a rollup and releases a brand new .MSI so we no longer have to use the original MSI package with the MSP patches.

I know it sounds counter intuitive to disable instant messaging in Communicator but some organizations may have legal or other reasons for disabling instant messaging inside Communicator 2007. You still get presence information and if you are using OC only for remote call control or VOIP, you might not need or want your employees using IM.

In the RTM version of Communicator 2007, it was not possible to disable IM, but with the new July 2008 update, you can!

Once the update is installed, you need to set a registry setting on the client machine. I am hoping they update the group policy .ADM files to include this new functionality (hint hint), so that I don't have to manually add this for my clients.

The registry setting in question:

DWORD value of "1", at location HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator\DisableIM.

Please note that without KB 954439 installed (the July 2008 Communicator update), the older versions of Communicator 2007 do not know about or obey the registry setting.

The KB article that describes how to disable the IM functionality is KB 954648, and is available online.

Also, somewhat related to this, is the Ethical Walls API example I wrote about here, and that related download is here. In that API example, it allows the administrator to place users into Organizational Units in Active Directory and to configure communication blocks between members of the different Organizational Units.

Update: KB 954439 updates the Communicator client to version 2.0.6362.76, and is online now as of 08-01-2008. You can request it from MS here.

Update 2: Updated registry key to proper location - thanks Russ W.

I'm not sure why there was a design decision to reserve so many UDP ports to take care of the DNS security fix (KB 953230). Thankfully, you can reserve ports that you know a service will need after the DNS Service starts up and you can also specify how many ports are reserved. I'm surprised a few of these well known ports aren't already reserved by default.

You can read how to work around this issue here at KB 956188. So far I have seen and heard it affecting ISA 200x, Exchange and a few other products that need well known UDP ports to operate correctly. I highly suspect but haven't confirmed that an OCS A/V Edge server will need reservations to avoid DNS stealing from its pool. Considering most edge installations are in a DMZ and/or a security hardened install, 99.99% of the installs out there will not be running the DNS Server service anyway.

My Xobni auto-updated and I noticed there were a few noteworthy fixes in this new version - a primarily cut-and-paste post from their forum:

The Release version is 1.4.3.4226. The release is being rolled out in stages, so you all should get this release over the next few days. It contains the following changes:

Fixes many cases of the incorrect Person.ME problem
Fixes some cases of endless spinning in Conversations
Fixes Xobni disappearing cases due to the regional settings registry key corruption, and points them to a FAQ entry
Improved profile load time performance
Upgraded Fun Facts

Everyone should get updated automatically over the week, but to get the Updater immediately, please visit the following link.

This bug: "You are prompted for your credentials three times and you receive an error message when you use the Outlook Anywhere feature to connect to an Exchange Server 2007 Service Pack 1–based server that is running Windows Server 2008", has been an extreme thorn in my side whenever installing an Exchange 2007 CAS server with Server 2008 as the host OS. Elan has a good writeup about it here. It is just unfortunate that it has taken this long for the issue/fix to be acknowledged and addressed.

There is also a known issue with the Outlook Address Book (OAB) not replicating properly in clustered Server 2008 environments, which is caused by 2 known bugs, and I'm still researching if this rollup fixes that issue. You can read more about the issue here and here, with a few workarounds until an official fix is released.

Download the rollup here, and read about the CAS/IPv6 issue here.

A big thanks goes out to Mark Derosia for portions of this information and a few of the links related to these issues.

Update: It looks like the published links in KB articles are incorrect and point to the old Exchange 2007 RTM Rollup 4. I am waiting for updated links to the real Exchange 2007 SP1 Rollup 4.

Update 2: All references to Exchange 2007 SP1 Rollup 4 has disappeared but a workaround has been identified in the meantime, according to this link on the MS Exchange site.

[snip from MS Exchange site]
The gist of the issue is that IIS7 uses kernel mode windows authentication by default. Turning this off will fix reprompting. I will post a detailed update once I dig through some more and talk to the IIS PD, but for now I wanted to provide this update so you can give it a shot and let me know if (no, "that") it works for you.
[/snip]

Here is a crash course on how to check your current settings with AppCmd that I have been using:

Run this command on your Client Access Server role servers:
%windir%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

To list the current WindowsAuthentication setting for IIS7, do:
%windir%\system32\inetsrv\appcmd.exe list config /section:system.webServer/security/authentication/windowsAuthentication

To enable WindowsAuthentication on IIS7 (in case it was turned off), do:
%windir%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /enabled:true

As time goes on and I get more Office Communications Server, Exchange 2007 UM and Cisco CallManager integration projects under my belt, the more I learn about the quirky nature of various implementations of SIP and how they interpret RFC behavior.

This problem between Exchange UM and Cisco Call Manager (CUCM) happens when you have "chained" call forwards, which causes diversion headers to be "stacked" with the trail of phone number extensions traversed.

Exchange 2007 RTM will read the bottom diversion header, and Exchange 2007 SP1 will read the top diversion header. The RTM behavior is the correct behavior when interfacing with CUCM, and most other SIP implementations, for the original caller to be identified correctly. The last diversion header contains the original phone number, which is what we want Exchange to use.

On a good note, we can take advantage of a CUCM bug that exists from version 6.0.x to 6.1.1b that will reverse the diversion header order, which works around the Exchange UM SP1 issue.

Workaround: Allow direct transfer to voicemail on the CUCM configuration and this reverses the order in which the diversion headers are sent.

(Un)fortunately, CUCM versions after 6.1.1 contain the fix CSCsl15554, which breaks this temporary workaround. CUCM 6.2 is becoming the popular standard for new deployments, with CUCM 7.x on the horizon. Microsoft is working on fix for Exchange 2007 SP1 to restore the RTM behavior.

I didn't figure out this trick/workaround. The people who are posting in this thread on TechNet are the ones who figured it out!

It is free, based on PowerShell, and has a lot of functionality not present in the native OCS MMC.

Check it out here.

Originally spotted here.

To use this, you will need PowerShell, PowerGui, and the OCS PowerPack.

Taking a tip from here, and due to the fact, in the current Intel/AMD chip architecture, only one hardware-based hypervisor can run at a time, you will want to create a special boot entry for a Hyper-V-less boot time configuration of Windows 2008.

Assuming you are currently booted into Windows 2008, at an administrative command prompt, type the following:
bcdedit /copy {current} /d "Windows 2008 (No Hyper-V)"

The above command should say:
The entry was successfully copied to {guid}.

Copy that {guid} to the clipboard including the curly braces.

Now, type the following command:
bcdedit /set {guid} hypervisorlaunchtype off

In the above command, replace {guid} with what you into the clipboard.

Boot into the 'Windows 2008 (No Hyper-V)' instance and you will no longer bluescreen while running VMWare guests.

This update adds support for the following Advanced Encryption Standard (AES) cipher suites in the Schannel.dll module for Windows Server 2003:
TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA and TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

With this update, you can support 128-bit and 256-bit cipher suites without Cryptography Next Generation (CNG). This update enables you to use a higher cipher strength. This update also fixes the interoperability issue between the Exchange server and the Sendmail server. This update also fixes the interoperability issue between the Exchange server and the Postfix server.

If you need your Server 2003 server to be able to read SHA2 certificates created with Server 2008's Certificate Services (of the CNG variety), which are more secure than RC4 based certificates, you will need KB 938397.

And last but not least, if you want to upgrade your Server 2003's IIS certsrv site to support Vista and 2008 clients properly, you'll want KB 922706.

Hopefully, someone at MS is watching and they will release all 3 of these updates as a Certificate Services update rollup for Server 2003 to make life easier for Exchange 2007/Office Communications Server admins that want to take advantage of stronger crypto.

After rereading my post here about buying the Hava device, I remembered that I never updated that post to reflect how I fixed Sabrina's PC lockup issue. Although I no longer have any of the crash dumps that happened while the Hava client was running on her computer, it seemed as though the system was crashing in the middle of processing a network packet. To go along with that theory, the network adapter in her older PC, a CNet Pro200WL, would stay 'lit up' on the physical interface lights on the card until the system was physically powered down. You could soft boot numerous times but the chip onboard would never recover from the crash. It was acting like a hardware bug or defect more than a driver problem.

Unfortunately, I think many of these cards at one time or another were bundled with Dell PCs because they were so low priced compared to quality chipsets. Her PC in question is a Dell PC that was donated to her by her grandparents not too long ago, much to her delight.

Running with that theory, and not wanting to have a kid constantly complaining about an unstable computer, I popped in my trusty SMC EtherPower, which is over a decade old. Not to be confused with the truly awful EtherPower 2, it is based on the excellent Digital DECchip 21140 (Tulip) chipset, which eventually was used as the "virtual chipset" that Virtual PC uses as an emulation platform for 10/100 ethernet.

Although it had higher latencies than some of the busmaster capable NICs that would come out after it, it was always a workhorse that had support in virtually every operating system. It has outlived a dozen of my personal PCs so far and was going to prove itself again in the year 2008.

Long story short: I put the old SMC network card in the 'practically new' PC and XP identified it correctly as an "Intel 21440 ethernet adapter". Intel bought the rights to Digital's network IP when Digital went out of business. I fired up the Hava client and no matter how many network packets I throw at the system, I can no longer blue screen the system once it starts seeing multicast/HAVA traffic.

Moral of the story: DEC chipset good, Davicom chipset bad.

This hasn't been my first encounter with flaky behavior from a Davicom network card. I remember having nothing but trouble under Linux with the Davicom network adapter that was built into a MSI Book PC.

Thanks go out to Allen Lamb for showing me this program.

Consider this scenario: You buy a brand new laptop or workstation from your local Big and Large to find that it has 10 or 20 various unneeded and unwanted trial versions of software on the system already. You spend hours uninstalling each piece of software individually, or get suckered into paying Big and Large to get their Nerd Herd to do it for you.

Solution: The PC Decrapifier

Not only does it have a funny "non-PC" product name, it does all the work of getting rid of these programs for you.

I could write pages of ranting about this trend in OEM builds that are sold at stores to subsidize the cost of the hardware, but that is for another day.
I could also write volumes about the trend of bundling applications together in deceptive ways. No software company seems immune/innocent of it anymore.

Little by little, the TV and the PC are merging.

Hava v1.7.4 has been released and, although it isn't listed as a feature of this firmware/software release, the picture quality coming from the composite, component and S-Video inputs from the Hava seem to have better picture quality when streaming on the local network. I don't publish the Hava device, which is much like a Slingbox without the one PC limitation, to the Internet, so I am not sure if the external video quality has improved at all.

Overall a very good update that seems to work perfectly fine on my rebadged Pinnacle box I bought off of Woot on a whim, which I wrote about here.

The device has been used so much that it now has a dedicated DVD player so that we can stream movies other than what is being shown out in the living room. The DVD player, Dish Network "TV1", Dish Network "TV2", the Wii, and the Xbox are all connected into a switchbox that leads into the Hava in case we want to stream any of those to the computer systems in the house. The Dish's HD content and the over-the-air HD channels I can pull in transcode amazingly well over the component input. Some people might consider that overkill, but we have found it to be an invaluable piece of hardware in our home audio/video system.

Today, my kids watched the Spiderwick Chronicles movie in their own rooms on their own computer LCDs while I watched something else on the PVR in the living room. Previously, we would have needed two DVD players, two copies of the movie, and two TVs to accomplish the same thing. Even better, they can pause the movie independent of each other if they need to go the bathroom because the software has the same kind of 'pause/rewind/fast forward' feature found in most PVRs, even though it technically isn't a PVR unit. I was a happy camper because movie time with both of the kids in the same room can sometimes result in shouting matches between them and fights over the remote control. Needless to say, they are very competitive with each other.

You can read the forum post announcing the release here and you can download the updated code here.

One other item of note: The setup/installation code seems to have improved vastly and I've been able to get the client software installed on some previously incompatible Windows OS versions of the 32-bit and 64-bit variety. I have even been able to get it to play decently under VMWare Workstation 6.5 using XP SP3 and the experimental 3D support enabled.

True geek moment: My Dish Network dish had been misaligned in the middle of the night at some point during my vacation last week and the only available client OS I could use at the time on my laptop with the older version of the Hava software was a VMWare XP SP3 instance. Not wanting to wake anyone up to watch the signal strength meter on the TV in the living room, I fired up the VM with the Hava transcoding the Dish output to my laptop over our wireless network. No walkie-talkie, cell phone or second person required.

Although I will admit I am biased against ZoneAlarm due to prior problems I've had with the product in the past, the July 2008 MS Security patch related to a DNS exploit does not 'play well' with the ZoneAlarm software. It is highly recommended that you download the updated version of ZoneAlarm from here before installing the security patch from KB 951748.

The initial knee jerk reaction to this problem might be to uninstall KB 951748, but I would advise against that due to the fact that there is an updated version of ZoneAlarm available.

Personally I am more of a fan of ESET's security suite and I have also had good experiences with Comodo's personal firewall, which is free. Of course, despite having a bit of a bad reputation in the past, the built in Windows Firewall isn't half bad these days either. You can even do per-process outbound blocking with Windows Live OneCare and the updated firewall in Vista and Server 2008 is much more feature-ful than what was included in XP.

Currently I'm "dogfooding" builds of the Forefront Threat Management Gateway at home on my EVDO connection and all the devices in our home are the clients. It is what would normally be called ISA 2008 or ISA 2009, renamed. The differences between ISA 2004 and ISA 2006 were pretty minimal, overall, for a compelling reason to upgrade from 2004 to 2006, but this version has a lot going for it, including Snort-like blocking signatures and other additions.

This problem occurs because a recent revision to an Office 2003 Service Pack 1 update causes some WSUS 3.0 servers to incorrectly synchronize the revised update with the update’s approvals. When the affected client computers communicate with such a server, the Web service is unable to process the approvals. Therefore, the detection is unsuccessful. To resolve this problem on a server that is running Windows Server Update Services 3.0 Service Pack 1 (WSUS 3.0 SP1), install the 954960 update.