I’d been under the impression – and said so at some recent conferences – that PowerShell can’t be used for logon scripts. Not so, it turns out, although I still don’t think it’s well-suited for the task.
Let me be clear in that I don’t think logon scripts themselves are well-suited to a task. The primary purpose of logon scripts is to map drives and printers; both are tasks, I feel, better accomplished in other ways. Users can be given UNC shortcuts (or just given UNCs) to access network drives, for example. Yes, I know, I hear you: “My users cant handle UNCs!” Yes, they can. DFS UNCs – \\company\users\donj, for example, rather than \\fs03frzwin03\donj$ – are easy to remember and write down, and you can make shortcuts to them. Force your users to use them instead of drive letters and within a month all the complaints will have gone away; catering to laziness – which is all most drive mapping is, really – just encourages more laziness.
But I digress. PoSH can be used as a logon script processor. Just run powershell -command scriptpathand it’ll work. However, there are a couple of reasons I don’t think PowerShell is great for this – and most of these reasons aren’t because PowerShell lacks capability, understand, but because PowerShell comes from a more modern, “post-logon script” world, shall we say.
First, PoSH doesn’t inherently have the ability to map logon drives. Yes, it can add a PSDrive, assigning a drive letter to a UNC, but that assignment doesn’t “show up” outside of the PoSH shell session (e.g., it doesn’t pop up in Explorer). You can instantiate WScript.Network and use the MapNetworkDrive method – but you could do that more easily from within VBScript, or do something similar and more easily in KiXtart.
Second, unlike VBScript, PoSH isn’t installed (now) by default on Windows, which means you’d need to deploy it. Deploying isn’t hard since you can use SMS or GPO or whatever to do so; but it’s one more step. Even KiXtart is usually pretty easy to deploy (and depending on what version you’re using, you might not need to “deploy” it at all).
Third, PoSH has excellent security, and by default doesn’t run scripts at all. So to use PoSH for logon scripts, you need to set all your machines’ PoSH execution policy to AllSigned (I won’t even get into how bad an idea it would be to sett every machine in your environment to any lesser execution policy).
So… yeah, while PoSH can run logon scripts, I’m sure that wasn’t a primary design consideration. I’d first seriously question the purpose of your logon scripts. I’m not saying they don’t exist, but I haven’t run across many logon scripts that didn’t exist solely to cater to user laziness, which is a horrible idea. I’d second question – assuming I gave in to the logon script argument – PoSH as my choice for logon scripts. I’d personally opt for a logon script language that was simpler and less capable of being used against me (VBScript doesn’t qualify for this, either, really, and KiXtart has gained too much functionality over the years, too).
The one argument I’d buy for PoSH as a logon script processor is its better security – you can ensure that only digitally-signed scripts run, which does make for a safer, more controlled environment. For example, control who has access to the code-signing cert, and you can create a workflow “choke point” to exercise change management over logon scripts. I like that idea. Of course, with TrustPolicy, you could be doing something similar with VBScript, too; PowerShell isn’t unique in this capability although it is much easier to centrally manage execution policy via Group Policy that it is with VBScript.
But here’s the real question: Do your existing logon scripts work? If so, just use ’em. No need to translate them to PowerShell. If you just want to translate them “for fun,” well, okay; I’m sure it’ll be a great learning experience and a decent way of becoming accustomed to PoSH. However… I wish I had that kinda free time!
But then again… it’s 2006. Almost 2007. We’ve been using logon scripts for nigh unto 15 years. Isn’t it time to stop it? I mean, if your users can remember www.TimeWastingWebSite.com, surely they can jot down a few UNCs for commonly-accessed files, no? And, remember, if you get a DFS tree on top of your existing UNC shares, users don’t need to know actual server names, and you’d be able to rearrange shares behind-the-scenes when necessary. Give it some thought, ‘kay?
