In search of perfection

[Christopher_Pai]

As I sit here I'm watching an SMS 2003 push of an application to 1306 machines. 25 clients never evaluated policy leaving 1281 machines that did.

Out of the 1281, 1206 have finished and 26 have failed with error 1603.

That leaves me with a push that is 93% successful. If weed out SMS problems and focus on only the ones that ran I'm looking at a success rate of 98% with a 2% error rate of 1603.

So is the glass half empty or half full? What kinds of error rates do you guys see? I'd really like to be able to crank up my reliabilty a notch or two because it costs alot of labor to have to track down these machines either physically or remotely and perform a manual installation.

Any thoughts?

[Jennifer_Watson]

We are still on SMS 2.0, but those numbers look about right for a package which you know works. I only rely on SMS reports as a framework...

[Christopher_Pai]

Well I found out that the 1603 errors are yet another manifestation of the IS DCOM server not likeing non-privledged users being logged on.

At this point I have to make a decision, tell SMS to log the user off before the install or dump all ISScript and go straight to C++ CA's.

I really like ISScript, but I'm really tired of impersonation problems despite my best attempts to fix them.

[Jennifer_Watson]

We stay away from ISscript at all costs. It causes more issues than it's worth.

Funny - I am suddenly running into DCOM issues today - launching Editor of all things... User is an admin, so it's not that. It just hangs on the user. Strange.

[bradyburke]

I'd take those numbers any day.

What about not running the installation in the user's context and using the Software Installation account? It operates in privileged mode.

Brady

[Christopher_Pai]

Enterprise standards forbid elevated privledges and generic accounts for security reasons.

I'm just not happy with the numbers because it can be very costly in terms of labor and availability. If my install goes wrong at say a ticket counter or a gate position it can have very bad consequences.

[Thaiboxer]

Hey Christopher,

I used to work for another airline, and you face a unique challenge - with all of your remote gate and service machines you need a higher success rate than most other enterprises.

We didn't use SMS for long, but we were forced to use elevated priviliges for our installs. For the most part, we forced our installs to run with the local system account on the target PC - that way you're never passing domain credentials for a generic account.

Good luck!
Mike

[Christopher_Pai]

Right, we run as System also, unfortunatly with the advent of DCOM this is not always enough unless we force the user to logoff since code executing as System can invoke DCOM servers that run as the interactive user instead of the launching user. Unfortunatly I hate to force the user to logoff but I'm increasingly leaning that way.

[Thaiboxer]

It's probably your best bet. Under the circumstances there's not really a great way to go.

Do you have predictable maintenance windows on your gate machines? Our agents were terrible about logging them off, so we actually wrote a service for it. All it did was pop up an always maximized dialog box saying "this machine will log off in 2 minutes, if you still need it click the button below to delay the logoff for 10 minutes". Something like that... it's been a while so I don't remember the wording or times very well.

[Christopher_Pai]

Check your PM's for a funny one.