How to remove Event Logs from Event Viewer

The Event Viewer management console has several categories depending on the roles of a server. All systems running Windows have Application, Security and System logs, or categories. These logs are represented by .evt files on disk, typically located in the %SystemRoot%system32config directory.

When a system loses a role, eg. it is demoted from Domain Controller to member server, the logs associated with that role remain in the Event Viewer console on that system. This can be quite annoying, not to mention misleading. Not only is the category retained in Event Viewer, but all the events are there as well.

I will not show you how you can remove these logs. The problem is that the .evt files are locked and cannot be deteled. They are locked by the the Event Log Service which cannot be stopped. The solution is to use Mark Russinovich’s excellent utilities PendMoves and MoveFile. You can find them here:

http://www.sysinternals.com/Utilities/pendmoves.html

Windows often needs to replace a file that is in use. This presents a problem when the process using the file cannot be stopped. To resolve this problem Windows has a spesial API that can tell Session Manager to delete that file, or replace it, on the next reboot. The MoveFile utility does just that. It tells Session Manager where to move, or delete, a file on the next reboot, before the system starts it’s services and applications. This info is stored in the registry key HKLMSystemCurrentControlSetControlSession ManagerPendingFileRenameOperations. You can write to this key using WMI or your own app, but I use Mark’s tool since it is already there.

To get rid of eg. the old File Replication Service Log from a server you would first go into Event Viewer and get the path to the .evt file by selecting properties on the log. Usually you would get C:WINDOWSSystem32configNtFrs.evt

Next, run the following command from the directory where you extracted PendMoves and MoveFile:

MoveFile.exe C:WINDOWSSystem32configNtFrs.evt “”

The “” indicates a NULL destination and is interpreted by Session Manager as a delete operation.

Now you can run PendMoves to get a list of any file move/delete operations scheduled for the next reboot.

But to get completely rid of the log we also will have to remove some setting in the registry, or else the Event Log Service would just recreate the file we deleted. The new file would be empty, of course, but the log would remain in Event Viewer.

Continuing the example with the File Replication Service Log, navigate to the key HKLMSYSTEMCurrentControlSerServicesEventlog
This is the main key for the Event Log Service and it has a subkey for each log that Event Viewer displays. Delete the entire key of the log you want to get rid of.

After the next reboot the logs should be gone from Event Viewer.

Sometimes they are not however. This usually happens because the service that uses the log is still set to Automatic startup. For example; when a DC is demoted to member server, the FRS service is not stopped and disabled. If this is the case the registry key you deleted will be recreated by FRS at startup and a new logfile created. So make sure to check all corresponding services before rebooting.

Meeting with Jesper Johansson from Microsoft

I just found out that I am invited to a lunch and later dinner date with Microsoft’s security guru Jesper Johansson. Jesper is a principal figure in Microsoft’s Trustworthy Computing program and is a frequent and popular speaker at the major Microsoft conferences such as TechEd and IT Forum. I have spoken with Jester at IT Forum before, but always very shortly and with thousands of people present. This time it will be only me and my colleagues from the Norwegian Microsoft TechNet Speaker Community. It will be a great opportunity to pick Jesper’s brain about security, a subject I feel strongly about, and anything else the conversation might turn to.

I am also invited to a seminar the next day where Jesper will be keynote speaker as well as hold some in-depth sessions. That also sounds very interesting.

I had the same oportunity earlier this year when I was invited to dinner with John Craddock and Sally Storey, but I had to cancel because I was going to Barcelona for a week 🙂

If you want to know more about Jesper Johansen and what he is up to (I recommend it), you can check out his blog:
http://blogs.technet.com/jesper_johansson/default.aspx

ExMerge and Outlook 2003 PST Files

Recently I was trying to import some PST files to an Exchange 2003 server using ExMerge. The PST files had been collected from clients that had previously been running POP3 accounts using various versions of Outlook. The import was part of a migration process where we moved from these POP3 accounts to Exchange 2003. Earlier we upgraded all clients to Outlook 2003 and created profiles for Exchange. Although all the clients were running Outlook 2003 now, some PST files had been created with previous versions of Outlook and some with Outlook 2003. As it turned out, this was a problem.

Upon starting the import job I immedialey started to get failures in ExMerge. This was unusual since I had verified all the PST filenames and made sure they matched the mailbox name in the Exchange database. I exmained the ExMerge log and found these errors:

Merging data from file ‘E:EXMERGEDATAUSER.PST’ to mailbox ‘User’ (‘USER’) on server ‘SERVER1’.
Error configuring message service (MSPST MS)(MAPI_E_EXTENDED_ERROR)(CMapiSession::CreateEMSPSTProfile)
Errors encountered. Copy process aborted for mailbox ‘User’ (‘USER’).
I had never seen this particular error before so I started to investigate.
After some research I found out that Microsoft changed the format of the PST and OST files in Outlook 2003 to eliminate the problems with the 2GB limits on these files that the previous verions of Outlook were hampered by. The new Unicode PST/OST files can be up to 20 GB and are in Unicode by default. The older versions of Outlook user ANSI. If you want to know more about this feature I suggest the fillowing links:
http://support.microsoft.com/kb/830336/
http://support.microsoft.com/kb/832925/
Combining this information with the error from the ExMerge log (CreateEMSPSTProfile), I guessed that maybe ExMerge could not read this new Unicode format. This was indeed the case, as the Knowledge Base article 823176 proved:
“The ExMerge utility does not support Unicode .pst files. If you export data from Outlook 2003, the default .pst format is Unicode. To work around this issue, create an ANSI .pst file. This is a .pst file that is compatible with Outlook 97 and with Outlook 2003.”
Here is the link to the article if you want to read all of it:
http://support.microsoft.com/kb/823176
The only soultion left to me in this case was to manually convert the new Unicode PST files to ANSI PST files. This was a very tedious process, that had to be done with Outlook 2003. First creating an ANSI PST file and the importing the Unicode file, and finally importing that file with ExMerge into the Exchange store. I could not find any utility to do this automatically or one to convert the file. Luckily for me there were only a few files out of the total that had to be converted.
The reason that I write this blog post is partly to share an interesting discovery with my peers, but also beacuse the error that ExMerge logs (CreateEMSPSTProfile) is not documented anywhere as being caused by an Outlook 2003 Unicode PST file. I think that it should be and so I blogged about it here. Hopefully Google will index this post soon and it will be available when someone has the same problem as I did.