- Deploying / Installing Software to Remote Computers
- Maintaining Legacy Script Files
- Heterogeneous Windows Versions and .NET versions
The main reason I don't use it for software deployments is the slower execution time. Compared with basic Batch/CMD scripts, or even VBscript, it just takes longer to "spin-up" the .NET and PowerShell foundation goodies before it even parses the script code. Multiply that by multiple installs per remote computer, and hundreds of remote computers, and the aggregate time difference can be significant. This is especially true on older hardware and older operating systems, which brings up the point of "pervasiveness" of PowerShell in a mixed environment:
Many environments I walk into (I'm a consultant after all) are not homogeneous when it comes to operating systems versions, or even "common applications". It's not unusual to find multiple configurations of .NET, Java Runtime, DirectX, MSXML, Oracle client, and SQL Native Client installations. One thing I rarely have to contend with is inconsistent support for Windows Scripting Host, let alone the ever-present CMD shell. I can't say the same for PowerShell. I wish it were as consistent and pervasive but it's just not. I'm sure that it will be someday, but we all know how long it takes customers to upgrade to newer operating systems.
To be fair, the same was true for Windows Scripting Host back in the early days of Windows NT. Microsoft cranked out several versions, until they finally stopped on 5.8 and let it sink in. That had a nice impact on most shops since they were no longer worried that as soon as they deployed WSH they would have to follow up with another upgrade. PowerShell is still evolving, so many IT managers aren't over-eager to deploy 3.0 when they seem to expect a 3.1 to come out any day.
I know it's not exactly logical to expect that PowerShell and .NET could be somehow combined and made to be more cohesive (for more streamlined deployment), it would help. The size of such a deployment package would be excessive for many shops to deal with, and might be tough to deploy on legacy hardware when local disk storage is almost maxed out. No, it seems Microsoft is betting on customers upgrading to Windows 8 and that would take care of everything as it pertains to achieving a ubiquitous PowerShell presence. I don't think that's going to happen anytime soon however, for a variety of reasons. So, for now, while I continue to expand my PowerShell scope, I am still dependent on VBScript and Batch scripts for many tasks.
I'm sure there are some of you out there that will shake your head in disbelief at all this, and that's fine. I welcome constructive feedback. So if you have some insights or ideas about how this can be managed more effectively, please let me know?