Corporate error reporting
There was a minor stink in the press a few months ago when someone noticed that Office XP's and IE's Error Reporting features sent a partial memory dump to Microsoft as part of an error report. To anyone who's ever debugged a program this was a pretty obvious thing, and if you actually read the messages in the Error Reporting dialogs it's pretty hard to miss the fact, but there's a valid concern nonetheless. Because the memory dump may include parts of the document you were editing, it may have confidential information in it.
That's why Microsoft created Corporate Error Reporting (CER), an application in the Office XP Resource Kit that lets you have those error reports go to one of your own servers instead of to Microsoft's.
You can also filter out parts of the information from all or from specific crashes, and then send what's left to Microsoft. Why would you do this? Two reasons: First, Microsoft looks at the crashes and may respond with references to knowledge base articles and downloads that may help you to resolve them. Second, it's just good for everyone that Microsoft have lots of information about why Windows and Windows applications crash, because it gives them ways to improve the products. Don't care? You don't have to send the data.
CER looks like it was developed for internal use and "productized" (sorry for the blatant marketing term) mostly as an afterthought. Once you get it set up it almost seems like magic, but setting it up can really stink. I'm sure I would have gotten it to work on my own eventually, but I needed a little help from Microsoft initially. The help file has a lot of information in it, but it's pretty dense.
A crash-reporting server can be run on Windows 2000 Server or Windows NT 4 (see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q309267 for details). You create a network share with a rigidly defined directory structure and then set policies (see below) to tell the clients to send their errors to that location. The server acts as a staging area for error information.
Periodically, you run the Corporate Error Reporting application and load the directory where the error information has been stored. You see each crash--called a bucket by CER--in a row of a table with information such as the name of the application, its version, the offset of the crash, and so on. You can report errors to Microsoft in the program itself, and they are sent via HTTPS. By setting a default policy for all buckets, or a specific policy for specific buckets, you can restrict which information is actually sent. Responses, including helpful URLs, come directly into the table in CER.
Setting up CER to work in all cases can be tricky; getting the client systems to report the errors to the CER server as opposed to Microsoft involves setting group policies, but this won't be straightforward until Windows .Net Server. Office XP comes with a group policy template to set policies (in User Configuration\Administrative Templates\Microsoft Office XP\Corporate Error Reporting) that will instruct Office XP on any Active Directory client to report its errors to the CER server, and these can be set as domain policies. (See http://support.microsoft.com/default.aspx?scid=kb;en-us;Q309268 for more details, including the registry keys you can use in lieu of policies.)
To get applications other than Office XP to report you need a Windows XP client. Today you can set the Error Reporting policies locally (Computer Configuration\Administrative Templates\System\Error Reporting), but you can't set them for the domain until Windows .Net Server comes around. The registry keys that correspond to the policies appear to be in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PCHealth\ErrorReporting\DW, but I haven't decoded them. With a little experimentation you can figure them out and push them to clients a dozen different ways.
The information you get can be really useful. Wouldn't you like to have the details about all the application and system crashes in your client systems? With this kind of database you could tell, for example, that certain types of hardware were prevalent in crashes, that certain applications were loaded during a high percentage of your crashes, or perhaps just that things don't crash as much as you thought. Wouldn't you like to know? Error messages are sure to get users to call either the help desk or you, so CER's ability to customize the message for your own users can be helpful. Implementing CER also allows you to act as a gatekeeper for all that data before you choose to send it to Microsoft or not.
Is your organization using Corporate Error Reporting? Do you find it useful? Post your thoughts in our Talkback forum below, or send an e-mail to Larry.