The solution was simple: Turn off all Sound Enhancements in Win 7. It’s important to check the “Disable all enhancements” box, because everything else does not seem to help.

Control Panel – Sound – Playback- Properties of Speakers – Enhancements

—————————
System.Xml.Schema.XmlSchemaValidationException: Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.Error: The element ‘SourceOrTargetServers’ has incomplete content. List of possible elements expected: ‘String’.

   at Microsoft.Exchange.Transport.RoutingTableLog.Parser.Parser.ValidateLog(XPathDocument doc, String schemaVersion)   at Microsoft.Exchange.Transport.RoutingTableLog.Parser.Parser.Parse(XPathDocument document)   at Microsoft.Exchange.Transport.RoutingTableLog.Viewer.MainForm.ParseLogBackgroundWorker_DoWork(Object sender, DoWorkEventArgs e)   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
—————————

This seems to be a bug in certain versions, and it is related to how the XML parsers reads the <SourceOrTargetServers /> tag. A workaround seems to be to remove those empty tags, so I wrote a quick & dirty powershell script. As always, use at your own risk.

Input file is any routing log file, Output file is c:\temp\routinglog.xml. You can easily change this to accept parameters as well, but I don’t use this often enough.

param ([String]$logfile= $(Read-Host -prompt “Input File Name”))
$fixedlog=”C:\Temp\RoutingLog.xml”

$erroractionpreference=”SilentlyContinue”
remove-item $fixedlog

$erroractionpreference=”Stop”
$log = get-content $logfile

foreach ($line in $log) {

 if (-not ($line  -like ‘*<SourceOrTargetServers />*’))
    {
    $line | out-file -FilePath $fixedlog -append -encoding ascii
    }

}

After running this script, simply open C:\Temp\RoutingLog.xml in the Routing Log Viewer and you should be fine.

An Active Directory error 0×80072020 occurred while searching for domain controllers in domain xxx.xxx

Remoting Exchange 2007  is not supported, that’s why it doesn’t work. There seems to be a workaround as explained here.

I didn’t try it myself because I avoid unsupported actions against production systems, but maybe it helps somebody else because I found it hard to find.

For the Exchange 2010 alerts, you can still create overrides like that, but you may find that there are only a few options, such as Enabled, Priority and Severity, but no obvious way to change a peformance threshold.

In my case I wanted to change the threshold for as low disk space error. To do that, find the alert in the alert view, right-click and open the Health Explorer. This view should show the actual monitor that raised the alert. Open the properties of the monitor and you should be able to set the overrides for more parameters, such as the free disk percentage.

Another way of finding this is to  go to “Authoring” in the SCOM console, open “Management Pack Objects” and go to “Monitors”. In the “Look for” box, enter the name of the alert that was raised, e.g. “The database copy is low on log volume space”. Make sure you identify the correct monitor (the example above will yield several results for different classes, some for mailbox databases and some for public folder database), then create a new override. Now you should see a host of other parameters, including the threshold for the free disk percentage.

After a while I noticed that I had forgotten to enable agent proxying for the SCOM agents (which is listed as a prerequistes in the Exchange MP documentation) so I turned it on, but the Exchange objects were still not discovered. Finally I flushed the health service state and cache (available as a task in SCOM), and since then everything looks good.

I knew that the DFSUTIL tool allowed for importing and exporting DFS roots, so here’s what I came up with. This is just a very simple batch – you will need:

• dfsutil (new version as in Windows 7 – part of RSAT)
• sed (a powerful stream editior usually found in Unix/Linux systems. Can be downloaded for free for Win OS
• Admin permissions to the DFS root servers

The principal is simple: Export the DFS root to a text file, modify the text file to match the destination server info, and import the text file. NOTE: This will overwrite the destination DFS-Root!!

dfsutil root export \\source\DFSroot c:\temp\DFSExport
type c:\temp\DFSExport | sed “4,5 s/source\\DFSroot/destination\\DFSRoot_Dest /” > c:\temp\DFSimport
dfsutil root import set c:\temp\DFSImport \\Destination\DFSRoot_Dest

Source Server = “source”
Destination Server = “destination”
Source DFS Root name = “DFSroot”
Destination DFS Root Name =”DFSRoot_Dest”

The magic is really in the SED command marked in red above. When you use dfsutil to export the root, it will store the DFS root server and share in the XML file, and it is not possible to import it to another server. The SED command simply rewrites the XML file by putting in the destination server and root name and saves it to the DFSImport file. Then DFSUTIL is used to import it to the new server.

One suggestion was to run regsvr32 inetcomm.dll, however that just yielded an error message, saying it cannot find the DLL entry point.

Since I was pretty sure that Outlook 2003 uses IE to render its HTML e-mails I decided to simply uninstall and reinstall Internet Explorer 8 because I was running both out of time and patience – and voila, after the reinstallation Outlook 2003 is displaying the HTML bodies just fine. Of course I still don’t know what caused the real problem or if there is a better solution, but at least it is a fairly quick and easy way of dealing with this issue.

I had to do that on Windows 2008 R2 and was then able to open help files from the local disks. When I clicked on the Help menu in my application however I still got an error:

Cannot display this help file. Try opening the help file again, and if you still get this message, copy the help file to a different drive, and try again.

I used procmon (another great Sysinternals tool) to determine which help file the application was opening, and I noticed that it went through a UNC path  (\\server\share\help.hlp) instead of using the local paths. Opening help files from other locations is blocked by default for security reasons, and the solution for this problem is also in the KB article linked above, so I set the “AllowIntranetAccess” registry value.

I still got the same error. I read the article again and noticed that his may not be the right location of the registry value since R2 is 64-Bit only, so I made the same entry in the Wow6432Node registry branch – again no success.

Back to procmon I checked to see if Winhlp32 was even querying the AllowIntranetAccess registry value, and of course it is not… Also no similar key/value, which leads me to believe that this is either a bug in the version for 2008 R2 or it was omitted on purpose. At this point contacting Microsoft support would probably be the way to go, but I didn’t feel like going through this for a rather small application.

In procmon I noticed that Winhlp32.exe also queries the following key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

This determines the zone mapping (e.g. Internet, Intranet, Trusted sites) for domains in IEs enhanced security configuration (ESC). UNC paths will be part of the Intranet zone by default. You can map a domain by creating a new key under this branch, using the domain name as the key, and then map each protocol to a zone by using DWORDS.

E.g.:
Create key: HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\MyServer
Create 32-BitDWord: http = 2

Now for the help files I have to assume they are using a file operation, so the protocol is “file”. As for the zone I mapped it to Zone 0, which is the local computer:

—

Windows Registry Editor Version 5.00

[HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\MyServer]
“file”=dword:00000000

—-

“MyServer” was of course replaced by the name in the UNC path… And bingo, it worked!
Please not that I used the Current User key in this example. You may get away with doing this in HKLM, however this required other settings to be active. I had this problem on a Terminal Server, so I added a login script that puts the registry value in the HKCU branch.

Looking at the issue it turned out the Simply Accounting Connection Manager did not start and this was most likely the root cause for the actual software not starting. The error message was the quite unhelpful 1053 error from the service control manager (The Service did not respond to the start or control request in a timely fashion) and no other errors were logged anywhere.

At this point we concacted the vendor’s support that had some OK advice (repair .NET framework), some rather strange ideas (stop the DHCP client service) and then the simple claim that is was our firewall. They were not able to give me any specifics (why the firewall, why suddenly, what ports would it need etc.), so I started looking at this using TCPView (Sysinternals). I sent a start control to the service while TCPView was running and this great tool immediately showed that it was trying to connect to crl.verisign.com. This means it needs to download a certificate revocation list before starting, probably because parts of the software were signed.

The machine could not connect to this URL because we don’t allow direct Internet access for our clients, so this worked as designed. I figured it was a quick fix and installed the ISA firewall client, a software that routes network connections over our proxy. I tried again and to my dismay it still tried the direct connection.

I then tried disabling the CRL checking (Control Panel / Internet Options / Advanced / Security), but that made no difference either.

At this point I decided to use a trick… I created a HOSTS entry on the client to assign an internal web server’s IP the name crl.verisign.com, e.g:
10.0.0.5     crl.verisign.com

Of course the server won’t have the needed CRL, but at least it can connect on TCP port 80. After flushing the DNS cache I started the service again and bingo, it started just fine.

Now this is definitely not a nice way of doing this, but at least we got the stubborn service to start and our accountant can work again.

I couldn’t find this with a quick search, so I just tested it
Result: If you want more than one standalone DFS-Root on a Windows Server 2008, you will need at least the Enterprise Edition of Windows. This does not apply to domain-based roots (this changed in Windows Server 2003 with SP2 or a hotfix)