We at Microsoft take product quality seriously and make every effort to avoid and resolve issues that adversely impact our customers.  Unfortunately, a bug with MOSS 2o07 Service Pack 2 (SP2) has been discovered that affects all customers that have deployed it for SharePoint Server 2007.

During the installation of SP2, a product expiration date is improperly activated. This means SharePoint will expire as though it was a trial installation 180 days after SP2 is deployed. The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes. Furthermore, product expiration 180 days after SP2 installation will not affect customer’s data, configuration or application code but will render SharePoint inaccessible for end-users.

Microsoft is working to release a hotfix to automatically fix this issue. A manual work-around is currently available and involves customers re-entering their Product ID number (PID) on the Convert License Type page in Central Administration.  For more information and detailed steps please read this KB article.

Microsoft wishes to assure their customers that this issue does not impact data integrity or their SharePoint deployment in any other way.

The team apologizes for any inconvenience this issue may cause you.

Q &A

Which products are affected by this?
Applying Service Pack 2 to any of the following products will result in this issue: Office SharePoint Server 2007, Project Server 2007, Form Server 2007, Search Server 2008 and Search Server 2008 Express.

Windows SharePoint Services 3.0 is not affected by this issue.

What can I do to fix it?
To work around this issue customers will need to re-enter their Product ID numbers (PID) on the Convert License Type page in Central Administration.  Please see this KB article for detailed steps.

Customers can also wait for the hotfix (available for free from http://support.microsoft.com) to resolve this issue.

Product ID numbers (PIDs) can be retrieved by logging into the Volume Licensing Service Center.

Note: For Search Server 2008 Express the only way to resolve this issue is to apply the hotfix.

What is Microsoft doing to fix it?
Microsoft is working on a hotfix and public update for the product. We will update this blog post with details and a link to the hotfix as soon as it is available.

Do I need to update all of the servers in my farm?
No. The Product ID number only needs to be entered once.

What if I haven’t installed SP2 yet but want to? What should I do?
You can continue to plan for and install Service Pack 2 for SharePoint Server 2007 with the additional step of re-entering your Product ID number after the installation is complete by following the instructions in this KB article. (The KB link is not currently active, it will be available within the next 48hrs)

Does this issue impact anything else?
The issue only activates the product expiration date. The activation of the expiration date does not affect the normal function of SharePoint up until the expiration date passes, at which point SharePoint will be inaccessible for end-users. This issue does not affect customer’s data, configuration or application code.

I can’t find/don’t know my original PID, where can I find it?
Product ID numbers (PIDs) can be retrieved by logging into the Volume Licensing Service Center.

There are a few things to keep in mind while installing Microsoft System Center Data Protection Manager.

One thing worth noting is that Data Protection Manager 2007 (‘DPM’ from now on) does not support being installed on Windows Server 2008 at the time of this writing. You will need to prepare a Windows Server 2003 machine. I’m using a Windows Server 2003 x64 Enterprise Edition with Service Pack 2 for this purpose.

Another important thing if you are installing DPM to protect Exchange Server 2007 SP1 running on Windows Server 2008 – you need a DPM hotfix to be installed for it to work correctly. The hotfix is KB950082 and it’s available from Microsoft Product Support. At the time of this writing, this hotfix has not been released in a rollup yet, but I’ve been told that it is a supported hotfix.

I installed this hotfix on my DPM server and successfully pushed the DPM agent on all nodes of my Exchange Server 2007 Single Copy Cluster running on Windows Server 2008 Failover clustering.

More updates on my adventures with DPM will follow.

While trying to open Outlook Web Access hosted on an Exchange Server 2007 Client Access Server, I get an error stating that Outlook Web Access could not connect to Active Directory, followed by a detailed stack trace:

Request Url: https://owaURL/owa/forms/premium/DirectoryView.aspx?ae=AddressList&t=Recipients&a=
User host address:
User: someone
EX Address: /o=MYORG/ou=MYOU/cn=RECIPIENTS/cn=SOMEONE
SMTP Address: someone@mydomain.com
OWA version: 8.0.685.24
Mailbox server: mail.mydomain.com


My initial search fetched a Microsoft KB article 919166, which deals with exactly the same problem. However, unlike the conditions mentioned in the article, the locale on my domain controller and Exchange servers are the same and my domain controller has Windows Server 2003 Service Pack 2 which supersedes the mentioned hotfix.

So I called Microsoft, and it turned out to be related more to KB886683 while OWA is querying the Global Catalog. To fix the problem:

1. Open ADSIEDIT.
2. Navigate to CN=Configuration, CN=Services, CN=Windows NT, CN=Directory Service
3. Right click on CN=Directory Service and choose Properties.
4. Edit the multi-valued attribute msDS-Other-Settings
5. If you see a string value DisableVLVSupport=1, remove it and change it to DisableVLVSupport=0 and add it back. Click OK all the way out.

Replicate the changes across all your domain controllers. You should now be able to open your address book.

I was just looking at the Windows Vista Problem Reports and Solutions feature today. Windows Vista has been observing each time an application crashed on my PC. What’s more interesting is that it was actually finding out what went wrong by searching for known solutions to the same problem.

All I had to do was click on each problem displayed on this window and a solution pops up. And the best part is that most of the solutions actually does work!

Hmmm… Self-healing Windows. Interesting.

In the RTM version of Exchange 2003, if you disable an active directory user account, mail flow to the disabled user’s mailbox stops. To a sender, it is as though the mailbox doesn’t exist.

With service packs, this behaviour has been changed. Hotfixes 916783 and 903158 make changes to the store.exe as follows:

If the SELF SID is missing from the Mailbox permissions, store.exe checks to see if the msExchMasterAccountSID is populated (this is the same as before). If it is not populated, then store.exe will use the objectSID of the user account, which should always be present.

This is good news for some administrators and bad news for others.

The good news is that if you want to temporarily restrict a user from accessing his mailbox but do not want him to lose out on receiving important e-mail, this is now possible. Also, if an employee leaves the company and you would like to configure an Out of Office message stating that he is no longer working there and at the same time disable the account for security purposes, this is now possible.

The bad news is that the above is not good enough for some companies. They just want to disable the account and forget about it. In such cases, administrators can adjust the delivery restrictions for the disabled user and configure that the user receive mails *only from* his own account. Or, you can configure ‘prohibit send/receive’ at 0 KB. Or, you can simple change or remove the SMTP email address of the user.

A problem has been found in the new Vista-compatible version of ISA Firewall client that was made available for download recently on the Microsoft website. [Read about it on my blog]

Programs like mobile phone connection optimizer software may install the Winsock Base Service Provider (BSP). BSPs sometimes bypass the Firewall client. To raise an alarm about the situation, ISA Firewall client displays one of those ugly yellow exclamation marks on the system tray icon. If you hover your mouse over it, it shouts “Firewall client is not installed properly”. An example of software that causes this condition is AT&T Comms Manager.

If this is too annoying for you, you can get rid of the warning:

• Download and Install the hotfix
• Open REGEDIT, find the key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Firewall Client 2004\Policies” and add a new “DWORD” value “UiEnableCatalogValidation” and set it to “0″ (zero).

So you went ahead and installed Windows Server 2003 Service Pack 2 on your Exchange 2003 cluster because it’s a “good thing” (Not that service packs are not good things, they really are!).

Everything went well until all of a sudden, your users report that they can’t access their mailboxes through OWA. They complain that they get the dreaded “500 – Internal Server Error” message in their browsers.

Its time to dig into the Microsoft Knowledge base. KB article 841560 suggests that you install Exchange Server 2003 Service Pack 1 on your cluster and install hotfix 841561.

And then… you should find your problems melting away.

Today I received a mail, supposedly from Microsoft, regarding a “security vulnerability”:

Click on the image to zoom

It had an EXE attachment “installation689.exe”. The message was written in the kind of language Microsoft uses to communicate with its customers – clear, courteous and concise explaining clearly what the update is for, etc. The first thing a novice (or even an intermediate) user would do, is to download the attachment and install the patch.

It even had the classic Microsoft footer:

Click on the image to zoom

Now, there are a few things that are revealed upon closer examination:

• The “from” address is suspicious: Network Security Center [xclocltwp@confidence.microsoft.net]. (Hmmm…)

• It addresses you as “MS” customer. It also uses terms like “MS Internet Explorer” and “MS Outlook”. Microsoft officially doesnt use “MS” to address itself . (Hmmm Hmmm…)

• Microsoft NEVER (never never ever) sends an update out to its customers as an email attachment.

• Microsoft update files normally have a filename that start with the letters “KB” followed by the KB article number.

What a clever way to outwit the unsuspecting user! So those of you out there, beware of stuff that comes in your e-mail! Think twice before you run an EXE attachment.

From my experience, 9 out of 10 EXE attachments are viruses. Sometimes they appear to come from people you know, because they are actually sent by malicious programs that have already infected their machines.