A customer of mine called in yesterday with a package replication issue.

After re-installing CMS afresh on a server they had they package server estate out of synch and not getting packages replicated, with varying numbers but on average 75~90% of the packages retrying download.

We started the troubleshooting following the usual avenues - from the Package Server logs to the SMP itself.

But the error came back at us on a couple of occasions - during a direct (from IE) hit to GetPackageInfo.aspx (using the download url from the PS verbose logging) and during profiling.

The error stack trace was pointing to a root cause outside of the Altiris realm:

Exception...
 at System.Net.Dns.GetAddrInfo(String name)
 at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
 at System.Net.Dns.GetHostEntry(String hostNameOrAddress)
 at Altiris.NS.Server...

This pointed to an environment issue and I dived straight into the code (using my favorite tool .Net Reflector). The reflected code clearly showed that the root cause was an error in System.Net.

So I decided to test this and crafted a quick unittest program, with the following source code:

using System;
using System.Net;
using Altiris.NS;

class unittest {

    public static void Main() {

        Console.WriteLine("Preferred NS host is {0}", Server.HostName);
        int i = 0;
        foreach (IPAddress a in Server.HostIPs)
            Console.WriteLine("Ip address ({1}) is {2}.", ++i, i.ToString(), a.ToString());
    }
}

Copying the Altiris.NS.dll to the C# source folder allowed me to invoke the C# compiler (CSC) and to produce an executable named quick test.

C:\Windows\Microsoft.Net\Framework64\v2.0.50727\csc.exe unittest.cs /r:Altiris.NS.dll

Here is the result from the unittetst with an error condition:

So, it was a problem with the NSPreferredHost registry setting that was using a name that the SMP couldn't resolve internally.

The solution is shown in the above screen capture - with a simple addition to the server host file!