Wednesday, December 22, 2010

Windows XP, Powershell and Deployment


Anybody who has read my blog would understand some of my frustration with running in environments with out-dated operating systems. Well, this post is another in a series of mini-rants about how new technology running on old platforms, mixed with half-hearted implementations has again contributed to sub-optimal solutions.

I’m currently running Windows Powershell 2.0 on a Windows XP machine. A large majority of servers are still running 2003 Server. This “antiquated” environment outright rules out the use of powershell remoting for updating servers during deployment.

This shouldn’t be a problem, as powershell comes with very useful, built in commandlets that allow you to interrogate processes on remote machines, connect drives and do a lot of other really fun things. Once again, this is where my environment comes into play. Production Web Infrastructure doesn’t use our internal Active Directory for Authentication. This decision was made many years ago for security reasons. The result of this is that we need to pass credentials to both Get-Process and New-PSDrive to allow retrieval of processes and to map network drives. Lets look at each of these commands.


A quick look at this command (get-help get-process –full), reveals that it doesn’t allow input of credentials. The only way to use this command is to be pre-authenticated with the target machine, and have the correct permissions.


This command seems to be a little better, it actually has a parameter for credentials. This surely must be a winner.. Right??

It turns out, that the parameters are just passed through to the provider specified using the PSProvider parameter. Unfortunately the FileSystem provider completely ignores the this parameter, resulting in this commandlet completely useless for our environment again.

Where does that leave us?

It leaves me using Powershell, mixed with WMI and Windows Scripting for something that should have been very easy to implement.

I’m sure that this usage scenario isn’t particularly obscure, and hope that future iterations of powershell clean up some of the loose ends around being able to provide credentials to commands instead of assuming that the current user has access to all network resources.

No comments: