Pushing the client
So when we made the big switch from Zenworks to SMS, we were in what I thought was a uniquely ironic position. We planned to use Zen to roll out the SMS client, then use SMS to remove Zen. There was something satisfying about that plan. Except, well, for the execution.
We pushed the SMS Client from our common software installation drive X:. That went great. We ran the client.msi from the S:\SMS_Client share and things went great. Clients started reporting, inventory started coming in. Great!
Then we removed the Novell client, and Zen, and started to really use SMS. To depend on it.
And noticed that clients were failing. And failing to repair. The error in repair log said, essentailly (and I'm paraphrasing here): "Hey! I can't find client.msi. I installed it from x:\sms_client. Tough luck!"
Of course we had made sure to replicate our x: software installation folder, this time in DFS instead of Novell. So when a user ran "repair" from the control panel, it worked fine. But auto-repair still wouldn't work. Turns out that the auto-repair function runs in System mode. So in 'system' mode there was no S: drive. And the SMS client appears, at least in our environment, to need to repair a lot.
It looked like we were going to have to push the SMS client again. I wasn't thrilled with the prospect. If we were in a simple one location environment it's no problem, we could push the client from the Primary site Server. But with numerous locations in numerous offices of varying connectivity, this wasn't really an option. And creating an MSI to push it out via GP didn't appeal to me either. The client was already on the workstations. Couldn't we just fix it?
Well it was a simple matter to give "Domain Computers" the rights to the DFS share, but this wouldn't map a drive. Where did the client get this mysterious "source list" that it used to try and repair? From MSI.If you go look at the reg key here: hklm\software\classes\installer\products\ 17E5DA380C0881846B4EAC62706B1A14 and in the Net subkey you'll find the path from which you installed the client.msi. In our case it indeed pointed to X:. A quick change of that key to point to the path of the msi via dfs \\unc naming, and viola! The auto-repair worked like a champ. Now a quick script via either vbs or cmd to load the reg setting change during login and our problem is solved.
I know some will say this may cause problems in the future. But for us, any update to the client will most likely be either from the same share or via SMS package. The same share is no problem, and an SMS package will re-write the location of the client.msi anyway.
Lesson learned (in this case, re-learned): always be aware from where you install your msi files, or use the /source switch to tell it where you want it to point for the msi if repair, re-install, or uninstall is intiated.