This site uses advanced css techniques
The Evolution payroll service-bureau software (from iSystems) running on the Windows middle tier uses a few UDP port numbers for its essential operation, and though they're not registered officially with IANA, no other software typically attempts to use them.
This means that when the Evolution services start, they'll find the ports unoccupied and will be able to use them exclusively. This has been the case for a long time.
But in Summer 2008, Dan Kaminsky found a serious security vulnerabilty in the Domain Name Service, and software publishers scrambled to modify their software to reduce the chance of exploitation.
Part of this fix involved using very large numbers (thousands) of random UDP ports instead of a few predictable ones, and Microsoft's implementation of the fix in their DNS server software has had a negative impact on Evolution.
Their approach to source-port problem is to pre-allocate thousands of UDP ports when the DNS server starts, and it randomly switches among them. This does indeed ameliorate the security problem substantially, and though it works properly in most cases, there can be limited — but not uncommon — cases where it happens to grab the ports that Evolution depends on.
Because the DNS service almost always launches earlier at boot time than the Evolution serices, if it happens to use the ports Evo counts on, Evo will simply fail to communicate with the rest of the system. This mainly effects the Deployment Manager and the ADR Client service.
Microsoft's solution to this is to allow a system administrator to reserve ports by number, so that the TCP/IP stack won't ever hand out those port numbers to a random-port request (they'll still be usable by programs that ask for specific ports by number).
Though this is mainly important for servers that run the Windows DNS server, we believe it's a best practice to reserve these ports on all servers simply to avoid rare — but painful — surprises
As of the Lincoln release, Evolution requires just a few UDP ports:
|9469/udp||EvDRClient.exe||ADR Client listens for broadcasts from Request Processors|
|9506/udp||EvDeployMgr.exe||Deployment Manager listens for traffic from Mgmt Console|
|9507/udp||EviMgmtCon.exe||Managment Console listens for DM broadcasts (sporadically; not listening all the time)|
None of these ports is normally ever used by Windows itself, unless some prior-starting service requests it as a random port.
Microsoft published a procedure to reserve ports so they won't ever be allocated randomly, and this fixed the problem. It's documented in Microsoft KB Article 812873, with procedures for Windows 2000 and Server 2003 (Server 2008 doesn't appear to need this).
Both instructions requiring visiting the same registry key:
looking for the ReservedPorts multi-string data value. If this data value does not exist, the instructions show how to add it, otherwise the reserved ports can be added to the existing list.
IMPORTANT - if existing ports are defined in the ReservedPorts value, do not remove them. You must add the Evo ports to the list, leaving the existing entries unchanged. We don't believe that the order of the ports entered matter.
In the Multi-String editor, the ports are entered this way:
Note that Windows 2000 uses REGEDT32, not REGEDIT - regedit on that platform doesn't allow for creating a multi-string value. Also note that all reserved ports are specified as a start-end range even if it's just one single port.
Once this has been saved, the easiest way to make it all take effect is to just reboot, but if one doesn't want to do that, these steps can do it:
Evolution should now work normally and consistently.
First published: 2009/04/27