I have a very simple MSI that deploys a small number of COM objects. It takes about ten seconds to run and works flawlessly. It was provided by the vendor.
I scheduled a job to push out this simple MSI to about 200 machines. I used a push delivery method that was set to reboot if needed and run from source. The source was a URL hosted by the core server.
I was very surprised to see that more than half of the machines reported a 1619, which I understand means the msi could not be found. I removed the ones that reported No Error and tried again. This time about half succeeded, half failed. I removed the successes, tried again and 2/3 succeeded. I did it again and they all succeeded.
Is this a scalability issue in LDMS 9 SP2? I wouldn't think 200 machines (or, in the second-to-last, about 60) would pose a scale problem, but that seems to be what happened.
It's a URL hosted by IIS on the core server and pointing to a virtual directory on a remote share. The remote share is hosted by a NetApp filer so I tend not to think there would be a scale issue there. It could have something to do with the distance between IIS and the filer, but we have 3ms response times so I've been focusing on IIS. But I would think IIS could handle 200 connections without breaking a sweat.
It may be rights. The filer does not have IIS so there is no way to grant IUSR rights to the box and there are some rather strange issues with IIS, rights, VUNC and using external shares. Why not just point the package to the unc path of the filer? Also look at the sdclient/msi logs on the clients that are succesful and see where they are pulling the patch from.
The virtual directory that was created in IIS uses explicit credentials to log into the remote share. This is the same virtual directory (different subfolder) we use for patching and we haven't had an issue. We originally wanted to use a UNC path but my understanding is that software distribution tasks run under the local system account and therefore would be unable to access any UNC path except one that was completely open (Everyone=Full is actually not open enough; there's a config change that must be set up as well).
All the clients pointed to the same location. In fact, my own PC failed on the first attempt and succeeded on the second. The local log shows two identical attempts, with the only difference being the result code (1619 the first time, 0 the second). It looks to me like the IIS server was only able to host 40 or so connections at a time, so repetitively repeating the job for failed machines utlimately solved the problem. I just have trouble understanding why the server would flame out after reaching such a low threshold.
The share does not have to be open - just give explicit user/group rights or domain computers read rights. You can also setup preferred server with explicit credentials to the shares. What is the specs of the server? Have you placed any IIS lImits (bandwidth, connection time outs, or limit the number of connections). Do you have any MCPs installed for SP2? I seem to remember some issues with SP2 and flaky downloads.
Why have I never thought of granting Domain Computers rights before?! I could swear that I had read that it just couldn't be done. Serves me right for getting my information from the Internet - Oh, wait...
Anyway, my Run From Source install using LocalSystem succeeded when I pointed the file to a UNC path that I had added that ACE to. Thanks.