wanna be sold on powershell...

anyone have good compelling reasons why?
 
Sure, WMI is easier, but I already know it in Wsh5.6...um...ya..eventually I guess I'll learn it, but really, maybe I shoudl ask....
 
Why did you start developing in it?
 
(I'm on the fence but the time sink to learn new code i'm dreading....I need to be pushed over  :)   )
 
THoughts anyone?

Probably the most compelling reason is that Microsoft management will be based on PowerShell going forward. Even if you don't want to use it for scripting, using PowerShell as a real management shell is worth the price of admission.  The other main advantage is that it is based on .NET which makes everything an object.  Once you start working with PowerShell you'll quickly realize why this is a big deal. You can take the results of one cmdlet and pipe it to another and then another until you get the information or result you want.

PowerShell is much more secure by design and out-of-the-box.

VBScript and batch files don't have to be replaced.  If they work and get the job done there's no reason to re-invent them.  PowerShell is just another tool in your administration and scripting toolkit. It isn't the right solution for every admin or scripting need and certainly has areas where it could be improved and expanded. Still, you should look through the PowerShell documentation.  Look at the PowerShell blogs. Take it for a spin.

That's my two cents.

I want to be sold too.  I wonder what type of tasks people are using PowerShell for. No code is necessary, but I'd like to know how they're leveraging its potential.  WMI being simpler to query maybe be a welcome feature for those who never bothered using it, but not necessarily for those who have.  I found an example in this forum where they did something like this:

$pc=[wmi]"root\cimv2:win32_computersystem.name='GODOT'"
$pc.totalphysicalmemory
$pc.roles

That's not too different than if I did it like this:
Set objPC = GetObject("winmgmts:Win32_ComputerSystem.Name='ComputerName'")
WScript.Echo objPC.totalphysicalmemory
WScript.Echo Join(objPC.Roles, VbCrLf)

Some say it is easy to learn, but it seems those who find it easy are those with a .NET or C# background.  In a way it's like you have to learn more than one language if you want to fully take advantage of powershell.  You need to learn it's syntax and how it works and then the .NET Framework.  I'm going to continue playing with it and trying to learn it simply because we really have no choice "going forward" as SapienScripter stated with Microsoft's Products.  I wonder how MS will implement this on a Enterprise level when each person could have their own profile with certain cmdlets, aliases, etc?

I don't think it's a matter of "selling" anyone on PowerShell.  As you use it, you'll realize where it fits in your organization.  It won't replace VBScript, WMI, ADSI, or even batch files for a long time. It is simply another tool that might work better for you.  For example, it is much easier to work with a local registry in PowerShell since it can be explored and treated as a drive. It does me very little when dealing with remote registries but if I'm on the server in PowerShell, I can do a lot very quickly.

As far as it's use in the entrerprise, already there are plenty of free enhancements and cmdlets from the PowerShell Community Extensions and others.  I think SAPIEN will even be offering some free cmdlets. Plus there are third party cmdlets such as PowerGadgets that provide graphs, dials and charts on top of PowerShell.  I did a few blog entries last month that showed how to use PowerShell to generate a file aging report and then extend it's functionality with PowerGadgets (http://sapien.eponym.com/blog/Scripting/WindowsPowerShell/_archives/2006/12).

Every user can have their own profile with customized functions, aliases and snappins.  In the short term, this might lead to so confusion when sharing scripts and code, but over time admins will develop a process.

Again, the biggest shift is from text-based processing to object based, which until you see for yourself is hard to appreciate.

So, if you have absolutely no VBScript experience, I'd start looking at PowerShell as my primary automation tool.  Realizing you may need to "backfill" with a little VBScript.  If you are already using VBScript, continue to use it where it works.  This is true even for batch files.  However, if you are feeling your scripts or batch files could do more or you were going to rework them anyway, take a look at PowerShell and see what functionality it offers that you can take advantage of.  Finally, keep an eye to the PowerShell blogs.  Maybe even pick up a PowerShell book (or two).  The more you learn about what PowerShell can and can't do, the better positioned you'll be.

I would like to know.
How would you write a script using PowerShell. e.g can it map drives printers based on user or group
What would it's file extension be, and will it run the same as a logon script through GPO.
And can you run it against Windows 2000 or XP machines.
I know it loads on XP but then would that mean manually rolling it out to all XP machines?

You wouldn't write a logon script in PowerShell.  That's not what it is designed for.  Things like VBScript and batch files still are needed for that sort of thing. PowerShell is a management shell that lets you write scripts.  On a simple level, it is a step up from the old CMD shell.  Whereas CMD was all text based, PowerShell is object-oriented based on .NET. In CMD you could put your commands together in a batch file.  In PowerShell, you do the same thing.  The file extension is .ps1.

PowerShell will only run Windows XP and later.  I don't believe MS every intends it to run on Windows 2000.

You use PowerShell to manage things like services, processes, file systems,registry, certificate stores and more. You can use the Get-WMIObject to access WMI locally and remotely.  Right now PowerShell has limited AD management capabilities and other than Get-WMIObject, not too much with connecting to remote systems.  But I expect that to change over time.

Any system you want to run PowerShell scripts will need .NET Framework 2.0 and PowerShell.  There is supposed to be an MSI for PowerShell so you can deploy with Group Policy or SMS.  There are also Group Policy settings to control PowerShell configuration such as script execution policy.

I think the more you use Powershell, the more you'll realize where it fits into your overall management strategy.

You wouldn't write a logon script in PowerShell.  That's not what it is designed for

 
Why not? Disregarding whether or not AD presently supports running .ps1 files at logon, what is inherent to Powershell that makes it inappropriate for logon scripting?

For starters, Powershell lacks native means to map drives and printers.  You can use New-PSDrive, but it won't be persistant and available outside of Powershell.  You could use net use or the VBScript network object, but then why bother with PowerShell?  I'm not saying it is impossible, just that I wouldn't spend any energy when batch and VBScript more than fill the need.  Personally, this comes back to the right tool for the job and PowerShell is not the right tool for most user logon scripts.

If there is some Powershell feature that you think would make a killer logon script I'd love to hear it.

I agree that right now vbscript/batch is better. Our logon scripts are linked very closely to AD (for better or worse). So when the changes to give powershell better access to AD go through I would think that in and of itself would make it apealing here. Or to use your own terms:
 
"PowerShell is a management shell that lets you write scripts"
 
At my work, logon scripts are management scripts.
 
"On a simple level, it is a step up from the old CMD shell"
 
Since batch files are essentially sequential CMD shell commands, then wouldn't that make powershell a step up from batch files regardless of the application to which the script is being applied?
 
"Microsoft management will be based on PowerShell going forward"
 
Again, I see logon scripts as Management tools.
 
So, I could easily support trhe assertion that powershell may not currently be the best tool for logon scripting, but your statement made it seem as though it would be patently wrong to even consider it. I won't be changing any of my logon scripts to powershell any time soon, but that is primarily due to a lack of availability on the client machines. In a year or two when we have universal powershell availablity and presumably the AD support and perhaps drive mapping support is better I will certainly consider it. In the meantime, I will conduct all of my powershell research with that possibility in the back of my mind and I would not want to preclude others from doing the same by flat out saying that it's just not something you would do.

I don't think I said I'd never use PowerShell for a logon script. If I did, you're right, that is an extreme position. I think we're in agreement that right now PowerShell is the wrong tool for logon scripts. At least as most people use logon scripts.  Some people use logon scripts to map drives and printers and that's it.  Others, like you it sounds like, take logon scripts as far as you can, and run all sorts of other other code under the user's credentials.  Certainly some of that functionality might be available or even better in Powershell, in which case once you get past the technical deployment issues, PowerShell could be an attractive tool.
 
Many of my other comments were attempts to answer some of the other questions about what PowerShell is and to provide some comparative context.
 
In the same way that VBScript has eventually replaced batch files for logon scripts and other automation needs over time, I expect the same thing to happen with PowerShell eventually.  But think about how long it took to make the transitiion from batch to VBScript.  I doubt the VBScript to PowerShell transistion will be as long but my guess is this won't be widespread until Windows 2000 goes the way of Windows 98.

I would like to run PowerShell as a computer startup script on Windows XP clients. Is it possible to do this by wrapping a PowerShell command in a batch file?

-Trevor Sullivan

I, too, need to move to Powershell and I was wondering for those who have been familiarizing themselves with the tool did you find any good books to learn from?

Steve

My favorite  book is Windows Powershell In Action:

http://www.amazon.com/Windows-Powershell-Action-Bruce-Payette/dp/1932394907/ref=sr_1_1?ie=UTF8&s=books&qid=1261492917&sr=8-1


I have also heard that Windows Powershell v2.0: TFM is a good book. Being familiar with the work of both the authors I would expect it to be:

http://www.sapienpress.com/PowerShell3.asp

Thanks, I looked at the book on Amazon, the first one, and I'm going to get it.
 
Time to buckle down and get powershell smart.
 
Thanks again and Merry Christmas.
 
Steve