If you are thinking of using PowerShell for a logon script - think
again. Much as I loved grappling with old DOS batch files and
perfecting the superior VBScript logon scripts, I admit there are better
ways of achieving a task than a PowerShell logon script. Whatever
your worthy project to control the users desktop environment, start with
Group Policy. Incidentally, even if you end up ignoring my advice,
you will still probably need a Group Policy to push out your logon script.
Back to PowerShell and logon scripts, PowerShell was designed as a
command line method for configuring the operating system and not for
tweaking users' environments. In particular, the security and script
execution methods employed by PowerShell are unsuited to running on client
machines.
Even if you succeed in getting a PowerShell logon scripts to run, you
have to ask was it worth it? Surely there must be a better way of
providing a default printer or access to a network share.
The problem is that you cannot simply assign a .ps1 file as a logon
script; because, by design, Windows 7 or Vista won't be able to execute
it. Fortunately, there is a work-around and that is to create a
VBScript script which calls your PowerShell script. To my mind
this whole procedure is telling me clearly, this is not the best way of
configuring logon settings.
However, if this is what you want, then PowerShell can play its part
via the -comObject. Here is a MapNetworkDrive example:
Note 1: Assume that you save the above code in
C:\PowerShell\logon.ps1
Note 2: Now call the logon.ps1 file from VBScript thus:
# PowerShell Logon Script Called From VBScript
Set objShell = CreateObject("Wscript.Shell") objShell.Run("powershell.exe
-noexit C:\PowerShell\logon.ps1")
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems. Fortunately, Solarwinds
have created a
Free WMI Monitor so that you can discover these gems of performance
information, and thus improve your PowerShell scripts. Take the guess work out of which WMI counters to use when scripting the
operating system, Active Directory or Exchange Server.
Version 2.0 transforms PowerShell's remoting, Windows 7 and Windows
Server 2008 R2 provide the menus to configure PowerShell scripts to run via
Group Policy.
Another option for running PowerShell scripts on remote Windows 7
computers is to use logon, logoff, startup, and shutdown scripts defined in
GPOs. Earlier versions of Windows supported specifying only command files
for these scripts. PowerShell provides far more flexibility and power than
is available in command files.
See more on PowerShell in
Windows 7
When Group Policy was delivered with Windows 2000, it allowed
administrators to execute batch file-based scripts at user logon or logoff,
as well as at computer startup and shutdown. This enabled administrators to
configure parts of the environment or execute additional programs during
those times. Windows 7 introduces support for executing PowerShell scripts
as well, giving administrators more comprehensive tools for real-time
configuration during these system events.
See more on Logon Script
Group Policy.
Although I spent many a happy hour experimenting with old DOS batch files and
perfecting the superior VBScript logon scripts, I now realize there are better
ways of achieving a task than a PowerShell logon script, start with Group
Policy.
If you like this page then please share it with your friends
Please email me if you have a better example script. Also please report any factual mistakes, grammatical errors or broken links, I will be happy to correct the fault.
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems.
Fortunately, Solarwinds
have created the
Free WMI Monitor so that you can actually see and understand these gems of
performance information. Take the guess work out of which
WMI counters to use for applications like Microsoft Active Directory,
SQL or Exchange Server.