Outlook 2003 update breaking Outlook 2007

I had Microsoft Office 2003 on my computer and decided to upgrade to Office 2007. Feeling a little wary about this upgrade, I decided to keep Office 2003 installed, since Office 2007 installer allowed for such option. However, as the installer informed me, Outlook 2007 could not coexist with Outlook 2003, so Outlook 2003 had to be removed. Alright, so I ended up having just one Outlook (2007) and two copies of Word and Excel (2003 and 2007).

A surprise came when I installed the next round of Microsoft updates (from our local WSUS server). An "Junk mail filter update for Outlook 2003" (KB931764) was offered to me, although I no longer had Outlook 2003. Not knowing what this means, I installed the update.

Right after that had an error in Outlook: "The File ExSec32.dll is incompatible with Microsoft Office Outlook. Install Outlook Again.", when opening any Outlook item. Apparently the "Junk mail filter update" reinstalled some of Outlook 2003 DLLs that were not compatible with Outlook 2007 (I guess this was the reason why they could not coexist in the first place).

I removed ExSec32.dll in Office11 folder, then get the same error about RTFHTML.dll. Removed it as well. Outlook items started to open, but after a few more errors, I resorted to reinstalling Outlook 2007.

Ever since then, each monthly update of Junk Mail Filter for Outlook 2003 was offered to me by Windows Updates, and I had to manually deselect it. Finally, when I uninstalled Office 2003, the problem stopped.

GroupWise vs. Excel

A long time ago a had to install Novell GroupWise 7.0 on my computer. Right after that I faced a problem with Excel 2003. To my surprise, the Windows "Close" button in the top-right corner (aka the "x-button") became disabled. Furthermore, sometimes when I was closing a workbook with Ctrl-F4, Excel would show the "Save As" dialog, even though the document was already saved. I suspected all this was caused by GroupWise, but since the annoyance was minor I didn't feel like spending time to figure this out. The situation became worse when I upgraded to Excel 2007. Now, whenever I opened a Excel file by double-clicking on it, Excel would come up, but the document would not open in it. I had to wait a few seconds, sometimes up to a minute, before the document would open. Interestingly, if I started Excel and then opened a document from it, it would open immediately without the annoying delay. This time I could not ignore the problem. Investigation revealed an apparently GroupWise-related file in c:\Program Files\Microsoft Office\XLSTART\GWXL97.XLA. I don't know what GroupWise wanted to do with Excel, but whatever it is, it is incompatible with Excel 2007 (the filename suggests it was developed for Excel 97). Removing the file resolved the problem.

Blogging from Word 2007

They say one can write blog posts directly from Word 2007. I am just curious. Let's see if it works.

Apparently it does! Although it's not as good as I thought it would be. I don't seem to be able to update a post once it is published. Instead, it publishes the modified document as a new post. Still, it's interesting and somewhat unusual for Microsoft

Trouble adding users to local groups

Had a problem today with a Windows 2000 computer. We needed to add a user to the local Administrators group, and could not. Just clicking the "Add" button in the group membership window resulted in error message "An error occurred attempting to create the Object Picker. An error with no description has occurred." Luckily a solution was described here in Hidev, Inc. Knowledge base. In our case, the key HKLM\LDAP\Clsid was missing. Thanks!

More on lingering objects

A followup to a previous post. I've been thinking how lingering objects appeared in the DCA domain controller (the one that didn't have the time sync problem). I have two theories:

Theory 1. While DCB controller was in year 2000, some objects were deleted in its copy of the Active Directory database. If things were going normal, DCB would keep a copy of these deleted objects in a "tombstoned" state for the duration of "tombstone lifetime" (by default 60 days). Within this period it would synchronize with DCA and tell it about the deletions, so DCA would delete these objects from its copy of the Active Directory database. But things were not going normal. When time on DCB was corrected, it found that those deleted objects were deleted 7 years ago, i.e. way longer ago than "tombstone lifetime". Consequently, the "tombstones" were deleted and it no longer had any memory of the deleted objects. All along, DCA continued to have copies of these objects, unaware of them being deleted. So, when the time was corrected, DCA wanted to synchronize to DCB, those objects were found to be lignering in DCA.

If this theory is correct, then the solution to delete lingering objects was the right one.

Theory 2. Nothing was deleted in DCB, instead something was created in DCA. While time was broken on DCB these changes failed to replicate from DCA to DCB. When time was corrected, DCB incorrectly assumed those new objects on DCA were lingering.

If this theory is correct, then the lingering objects should not have been deleted. Instead, Strict Replication Consistency should have been disabled (as described, among other places in the Event ID 1388 or 1988: A lingering object is detected section of Active Directory Operations Guide at Microsoft Technet) and thus objects allowed to be recreated at DCB.

Somehow I feel that Theory 1 is correct, but I have no definite proof.

Wrong Time on a Domain Controller

Today we had to shut down all our servers for electricity maintenance, and while they were starting back up after the maintenance, clock was set incorrectly on one of our two domain controllers. I am not completely sure why this happened, but it seems to be the fault of Tardis Internet time service. One way or another, time was reset to Jan 1st, 2000. All the hell broke loose.

First, the wrong time was picked up by some other computers that suddenly shifted to year 2000. That was the least of all problems. Second, users started having problems logging in to the domain. The faulty domain controller denied access due to clock skew. These two problems were resolved once the time problem was noticed and time at the domain controller was reset to the correct value. But this was not the end.

Unfortunately, while the faulty domain controller (we'll call it DCB) was in year 2000 it replicated with the other controller (let's call it DCA) that had the correct time. Then DCA remembered that it last replicated with DCB in year 2000! As the result, when the time on DCB was corrected, DCA no longer wanted to replicate to DCB thinking that it was way too outdated to replicate again. Attempts to force replication in replmon utility (from Windows Support Tools) resulted in the error "The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime." Directory Service Event log on DCA showed Event 2042 which read:

It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source.

The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machine might return objects which have already been deleted.

This problem soon had consequences. One user reported that her workstation could no longer connect to shared resources on the DCB controller, with error message "Target principal is incorrect". It was a strange situation, since it could connect to any other server in the network, plus all other workstations but this one could connect to DCB too. Although I still don't have a definite explanation to this, my best guess is that this workstation had the bad luck to automatically change its domain account password while the replication was broken. As the result, DCA had its new password, but DCB still had the old one, and thus could not authenticate the workstation.

To resolve the replication problem I followed the advice from the Event 2042 log entry and numerous sources on the internet, such as "Event ID 2042: It has been too long since this machine replicated" chapter from Windows Server 2003 Active Directory Operations guide on Microsoft TechNet. On DCB I went to the registry key HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters and created a DWORD value Allow Replication With Divergent and Corrupt Partner with value 1. Then forced replication from DCA to DCB in replmon. This time replication worked, and after that I reset the registry value to 0.

Still, replication in the other direction, from DCB to DCA didn't work. Directory Service Event log on DCB showed Event 1988 which read:

Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as "lingering objects".

This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database. This replication attempt has been blocked.

The best solution to this problem is to identify and remove all lingering objects in the forest.

Additionally, the Application event log was flooded with Event 1053 that read "Windows cannot determine the user or computer name. (Access is denied.). Group Policy processing aborted."

At the edge of panic, I searched for suggestions to Event 1053 error. In retrospect, I'm not sure I did the right thing, but I followed the advice from the Microsoft KB article 288167 (or 260575) to reset DCB's computer acccount password with netdom utility. After the password was reset and computer rebooted, the problem of the workstation that could not connect to DCB's shared resources disappeared.

It remained to restore replication from DCB to DCA though. I followed "Event ID 1388 or 1988: A lingering object is detected" chapter from Windows Server 2003 Active Directory Operations guide on Microsoft TechNet (there's also a few KB articles that you can find if you search for "lingering objects" at support.microsoft.com). Using repladmin /removelingeringobjects on DCA, as described there, I removed the objects that stopped the replication, and the issue was finally resolved.

In retrospect, I don't fully understand how those lingering objects occurred and if it was safe to remove them or not. Perhaps I should have disabled Strict Replication Consistency as described at the same TechNet article or in the Event 1988 log entry.

To wrap up this post, don't mess with time, it's important.

Dangers of Group Policy

As any powerful tool, Group Policy may cause trouble if used inappropriately. Once I have set the following parameters in our domain's default policy: Computer Configuration - Administrative Templates - Network - DNS Client - DNS Servers and DNS Suffix Search List to the values appropriate to our LAN. I must admit that in doing so I didn't pursue any particular purpose, since these settings were configured on all client computers either manually or with DHCP. It just seemed a right thing to do. Wrong. Recently we started using a laptop computer to access the Internet wirelessly via GPRS while on the road. All went well until the laptop was joined to the domain. Suddenly GPRS connection no longer worked. Investigation revealed the following: once the laptop was joined to the domain, Group Policy applied to it, including our internal LAN DNS Server setting. Then, unexpectedly, the computer continued using this DNS Server even when disconnected from the LAN and connected via GRPS, which, of course, didn't work. To resolve the problem I simply removed these settings from the Group Policy, then connected the laptop to the LAN and ran gpupdate to update Group Policy settings. I guess if I did need these settings in the Group Policy I would have to move the laptop to another OU in the Active Directory so that this particular policy would not apply to it.