I had an interesting experience today. I was setting up an Exchange Edge server for a customer. After configuring the TCP/IP settings I proceeded to the Exchange Management Console to enter the server’s product key. I had already prepared the server earlier, installing Exchange and all required patches. But when I selected Properties on the Edge server this error popped up:
An error happened while accessing registry of the specified server: “<server FQDN>“. The error
message: “The network path was not found.”
It was running the command ‘get-exchangeserver –Status –Identity ‘<Administrative Group GUID>‘
I thought this was very strange since I was managing the server locally and not over the network. I remembered that Exchange has a history of requiring the Remote Registry service for various management and installation operations, even if you are managing a server locally and installing Exchange from the console. That service was running, so that was not it in this case. But then it struck me, if Exchange requires the Remote Registry service when performing local operations, it follows that it uses the network redirector to access itself, and in turn the server service to communicate with the Remote Registry service. I immediately brought up the configuration settings for my network card and found the cause of the error. Earlier when I had configured the TCP/IP settings I had removed the bindings for Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. I did that because these services were not needed for a server that was only supposed to communicate using SMTP, LDAP and RDP, or so I thought. After enabling the bindings again the error disappeared and the server is now functioning normally.
It seems strange that Exchange depends on using the Remote Registry service to perform local operations, especially on an edge server where enabled services should be kept at a minimum. I believe that it lets the programmers implement only one way of administering Exchange; through the Remote Registry service. Otherwise they would have to create two interfaces, one for remote admin and one for local.
Evidently the Transporter team has released an updated version of the Microsoft Transporter Suite for Lotus Domino. I can find no updated release notes or any information about any changes. Then only evidence of an update is the size of the installer and the version reported by the management console.
The old Transporter.msi file has a size of 8638 KB and the new one has a size of 8685 KB, in Explorer.
You are not allowed to update your current installation, but rather have to uninstall your old version first. Seems strange to me.
You can download the new version from this link:
Another peach of circumstantial evidence appears on this page; the publishing date is 05.04.2007. The original version of Transporter was released on 15.02.2007 (Valentine’s Day).
Hopefully more info about what has been fixed/updated will be available soon.