Weekend Shell: There is Only One PowerShell

I've recently been encountering a LOT of confusion about one of the basic aspects of how PowerShell works. The problem seems to arise because some of the Microsoft product teams, such as Exchange Server, create an "Exchange Management Shell" icon upon installation. This leads to the misperception that there are "many" PowerShells... and there aren't.There is only one PowerShell. 

PowerShell works a lot like the MMC in this regard. The MMC is empty, and not capable of much; you add snap-ins to give it functionality. Microsoft usually creates icons for consoles that pre-load certain snap-ins. That is, when you open Active Directory Users and Computers, you're opening the same old MMC - but it is pre-configured to load the ADUC snap-in.

That's how PowerShell works. There's one shell. It can be extended by snap-ins and by modules (which are close to the same thing - they're just different distribution mechanisms, and modules are the preferred way as of v2). If you open the "basic" shell, you can add the Active Directory module to manage AD, the SQL Server snap-in to work with that product, and so on.

Microsoft product teams often create a "management shell" icon when they install, but that icon isn't a brand-new version of PowerShell. It's just a shortcut that loads powershell.exe with a command-line parameter to pre-load a given snap-in - just like the MMC.

Like the MMC, PowerShell lets you load as many snap-ins (or modules) as you like. Want to combine SQL, AD, Exchange, and SharePoint? You can do that. And you can even export a "console file" (using Export-Console) that remembers which snap-ins you have loaded. Later, you can run PowerShell.exe with a command-line switch to re-load that entire "console," bringing all of your snap-ins back online. 

The nice part about PowerShell is that you really only have to learn a limited set of "patterns" to use all of the various PowerShell snap-ins and modules. Learn to use the AD module, for example, and you're well on your way to understanding how the SharePoint module works, too. Eventually, you'll fall into an easy ability to understand new modules as Microsoft releases them, meaning your ongoing learning curve will be shallower, thanks to your initial PowerShell investment.

Update: In response to one of the comments below, let me clearly state that you CAN perform MULTIPLE tasks within a SINGLE shell session. On a Windows Server 2008 R2 machine, for example, I can run Import-Module ActiveDirectory to load the AD extension; I can then run Add-PSSnapin to add the Windows Backup features or the SQL Server extensions (assuming they're installed on that computer, of course). I can load the Exchange extensions into that same shell, too. This is EXACTLY how the MMC works - you aren't stuck using the default, single-purpose consoles Microsoft provides, and you're not stuck using the default single-purpose shell shortcuts, either. In fact, examine the shortcut for the Exchange Management Shell and you'll see that it's just running PowerShell.exe with a particular extension pre-loaded - you're not prevented from modifying that to load additional extensions by default, if you like. 

Discuss this Blog Entry 20

BartekB (not verified)
on Jun 28, 2010
Well, I would not expect v2 commands to work in Powershell v1. Upgrade to the recent version is nothing unusual in 'my' IT Pro - world. ;)
So yes, I've tried import-module on older OSes (XP, W2k3) and it worked perfectly - only thing I had to do was to download and install Powershell v2.
So first: make sure you use current version of Powershell if you want to take advantage of recent features.
Then: create you own shell by importing modules and adding snappins. (Get-PSSnappin -Registered; Get-Module -ListAvailable), choose what you need, put proper command in $profile and - voila - one shell to rule them all. ;)
I can do the same with MMC as Don mentioned: can load all in one console, but can select from one pre-configured by MS. Same applies to Powershell with note, that some stuff is working fine with v1, some (newest) features require v2.



Poshoholic (not verified)
on Jun 27, 2010
Console files are a nice idea in theory but in practice they aren't designed well by their respective teams. This has been covered before:

http://poshoholic.com/2008/05/20/essential-powershell-use-non-portable-console-customizations-sparingly/

It's too bad really because this issue is hit by seasoned admins all the time and it gives a bad first impression of PowerShell.

Murat, you obviously have not had a good experience with PowerShell so far. Rather than simply dismissing it as more of the same though and replying with brash remarks, you might find you get much farther if you actually share your experiences and participate in the community. Who knows, you might just be surprised with what comes out of that effort.

Of course, PowerShell (and scripting and programming) in general are absolutely not for everyone. If you do find yourself in the group of people who are not inclined to dig into PowerShell and learn more about how it works and what it can do for you, then why waste everyone's time here?







ikkarus (not verified)
on Jun 27, 2010
I understand what the person is saying, and it does seem as if there are different powershell's. Like he said if you click on the default powershell icon you can not perform ad or exchange tasks. However with 15 - 20 minuets of research you can configure the shell to do whatever you want. When you run the exchange shell, it executes the same powershell as the icon you see under accessories. However the exchange shell loads the snapins needed for exchange tasks. Just like dos, or linux shells, powershell is very configurable, and you could configure it to load any snaping at any time. For example everytime I start my shell it loads the Quest AD snapin, and specop snapins. It was not hard to figure out how to do it. As a matter of fact I think it was Don that showed me in one of his classes.

on Jun 27, 2010
Don, you're right, I'm mistaken. PowerShell is the greatest product, it is the future of system programming. It's so easy even a child can do it. It's versatile. And the elephants do have wings.
jsnover (not verified)
on Jun 27, 2010
1) Don is correct.
2) If you ever find yourself thinking Don is wrong about something he says about PowerShell, your best bet is to double check first. I invented the thing and that is MY policy. (seriously)


Jeffrey Snover [MSFT]
Distinguished Engineer
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx








ikkarus (not verified)
on Jun 27, 2010
I understand what the person is saying, and it does seem as if there are different powershell's. Like he said if you click on the default powershell icon you can not perform ad or exchange tasks. However with 15 - 20 minuets of research you can configure the shell to do whatever you want. When you run the exchange shell, it executes the same powershell as the icon you see under accessories. However the exchange shell loads the snapins needed for exchange tasks. Just like dos, or linux shells, powershell is very configurable, and you could configure it to load any snaping at any time. For example everytime I start my shell it loads the Quest AD snapin, and specop snapins. It was not hard to figure out how to do it. As a matter of fact I think it was Don that showed me in one of his classes.

MeltonDBA (not verified)
on Jun 27, 2010
@murat
http://www.windowsitpro.com/author/1860/Murat+Yildirimoglu.aspx, I have to say it is very unprofessional the way you replied (if you are the same person from the link). Especially since you are a fellow author on WindowsIT Pro.

I believe you did miss type in your first reply..."an admin point of view"...I believe this is purely your point of view. As an admin, I believe the people that actually do admin work see PowerShell as a great improvement in performing administrative task. Those that don't know or are unfamiliar with PowerShell (as I am right now, but learning more and more thanks to Don and Sean McCown) probably feel the same as when VBScript first came out. It is something knew to learn upon and utilize as you see fit. If you don't want to learn it, then don't and as they say "get left behind".

If you have to work with multiple providers (exchange, sharepoint, sql, etc) and option I found from this site (http://www.petri.co.il/forums/showthread.php?t=47191) is making a profile that allows you to load all those at one time so you are more than ready to tackle any task at hand. I think that is awesome.




jaleel (not verified)
on Aug 10, 2010
you guys make me sick and its the reason why this industry is imploding
on Jun 27, 2010
Dear Don, it is not a simple confusion, it is for real. There are different PowerShells. Whether they are only extensions to single shell, from the admin point of view, they are different. When you want to do some Exchange related tasks you can't use the one that comes with the OS, you must use Exchange PowerShell. When you want to do some AD related task, say enable AD recycle bin, you must use PowerShell AD extension. Then, they are different and this point limits the usefulness of PowerShell. It is not the only disadvantage. PowerShell is to much complicated.
İn 1980s and 90s, it was said that programming would be so easy that even a child could do programming. The result is only a few select people now can do programming. PowerShell will do the same for the system programming. Admins will not be able to do even the dumbest things programatically.
on Jun 28, 2010
BartekB, you are right, you can do anything at all. Download some new, updated versions, install and use them. But, even after applying SP2 to a Windows 2008, it is not there; you should do the procedure you mentioned. But why is it so? Why do I have straight command prompt in addition to PowerShell? Why are there so many consoles, even if they are only shortcuts? Why is all this fuss?
Command shell had always been there: Ready to be used. With PowerShell, you must recognize the version differences, download and install updates, learn all the complexities, etc.
And the last disadvantage: PowerShell is too verbose. You must type many letters, words to do something usefull. Are we Linux guys?

on Jun 27, 2010
Murat, I'm afraid you're absolutely incorrect, although what you have said is a common misconception.

If you want to do some Exchange related tasks, you absolutely CAN do them in the PowerShell that comes with the OS - you just use Add-PSSnapin or Import-Module to load the Exchange "stuff" into the shell session. You DO NOT have to use the "Exchange" PowerShell. I'm afraid you've completely misunderstood the way the shell is extended.

I can open the "Exchange" shell and load the AD module (Import-Module ActiveDirectory) - and perform AD tasks. There are NOT multiple shells. You CAN do any PowerShell task from within any shell - because they're all the same shell, just with different extensions loaded BY DEFAULT (meaning you can change those defaults and have different extensions loaded if you like).

You're right in that, to perform AD tasks, I have to load the AD extension. But I can also load the Exchange extension. System Center Virtual Machine Manager. Operations Manager. SQL Server. Whatever. I can have them all loaded at once in a "super" PowerShell. You're not stuck using the default shell configurations that Microsoft provides - not at all.

This is no different, as I said in the article, than the MMC. You can make a custom MMC console that contains AD, Exchange, and whatever; you can do the same thing with PowerShell, if you like.

I'm sorry you feel the way you do about the shell, but you definitely have some incorrect information, perhaps that you picked up elsewhere. Maybe in time as you come to understand how the shell really works, some of your feelings will change.









BartekB (not verified)
on Jun 28, 2010
I'm not expert on MS definitions but for me upgrade from v1 to v2 is not a fix, so it's not a SP-like change. I also not a type person that will assume Microsoft knows better. In fact I use Quest cmdlets on a daily basis and this is 3rd party tool.
You mentioned however one point that I think is critical for understanding: why powershell. You say too many letters? I guarantee that once you get accustomed with the language you will see that even simple 3-4 click-of-the-mouse task is easier to do with powershell console + tab completion + aliases + partial parameter names and aliases.
I don't see a point in forcing you in any way to do it in powershell - if you prefer to click your way thru life or have someone else to write a program that will do the job for you - it's your choice. But clicking is repetitive only in MS Office, when you record a macro... ;) With a command, function, script, module - I can do it once and take advantage of it ever after.
And last but not least: I'm not Linux guy, I haven't used it for years now. But being Windows guy for 10 years now I don't feel bad with any command line tool. And speaking of 'many consoles' - have you used many cmd tools? I did, and it was a pain. Powershell is a joy. Try to get useful information with wmic.exe and Get-WMIObject, you will see the difference in a blink of an eye. ;) And why does consoles exist? Because it's easier to prepare .lnk with proper set of tools than to explain to newbie how add-pssnapin, or import-module. And if he will decide that he actually want to add-pssnapin to different powershell .lnk, he can learn it same way he found out that set of tools in 'Administrative tools' it's not all you can get when working with mmc. That's why Don's analogy with mmc was, in my opinion, accurate.


Marco Shaw (not verified)
on Jun 27, 2010
Several months back I encountered someone in a forum bashing PowerShell. I commented, he took offense similarly to murat.

I'm busy, try to be as effective as possible. I can't think of a time when I've knocked anything I've used relating to computers. If something didn't "work" for me, I moved on. I do believe that everything does have its place and have learnt to appreciate every OS, every scripting/programming language, every tool that I've come across, for what it does provide, not what it doesn't.

I never bashed DOS/BAT scripting because I couldn't figure out how to do date manipulation, I just used Perl or VBScript instead.

I like PowerShell for several reasons. I like the built-in help format and how I can leverage having learnt something either in its core or by working with the Exchange Management Shell.

You eventually learn that Get-* helps you retrieve stuff. Think how much fun it was for me to not have any System Center Operations Manager 2007 experience, but to open a PowerShell console and without hesitation, type "Get-Alert", and it actually worked...

No need for me to re-iterate the others comments. I decided to take a different approach...









Ikkarus (not verified)
on Jun 29, 2010
Murat,

I can remember commands being outdated, in every shell. Have you ever tried to pull system infomration across different UNIX environments. Windows server 2008 and Windows Server 2008 R2 are not the same OS. Not when they are service packed not when they are patched. For Example Windows Server 2008 R2 is x64 with .net 3.5 only, Windows Server 2008 can be x32 or x64. However the shell changes on different OS's it does not change the argument. On any one OS there is only one shell loaded with different modules or snap-ins if you prefer.

BTW Dos changed commands quite a bit in it's versions.

Say what you want but I am migrating all our user accounts to new logon names (sam account names) migrating their home directories, PST directories, filling all missing user information, forming our OU structure for users, creating a personalized instructional web page and dropping it in their new home directory, creating new home drive folders, setting permissions, and creating alternate shares for the pst directories all by using a power shell script.To do the same thing in Dos batch files, or vb script would be pure hell.

That is 2300 users I can change in about 30 minutes (users are responsible for copying the files they need to keep). I have to slow the process down to allow the help desk enough time to answer user questions. The HR system will out put changes to employees that will be reflected in AD automatically because of the scripts. One month of intense work and now I am literally waiting my way through the migration.

You don't have to accept power shell, but it seems as if you want to find a problem that does not exist. Since you can do just about all the things you can do in cmd with ps. Just fire up ps instead of using cmd, eventually you will find yourself moving away from dos to ps.













on Jun 27, 2010
Murat, I wasn't trying to be insulting. I also wasn't implying that PowerShell is perfect or great. I was trying to correct a misconception that many folks have. I've frequently found myself misunderstanding things about new products when I was learning them, and I've always appreciated someone pointing out the correct answer for me. I apologize if you were offended, but in this case your statements were not technically correct, and I wanted to try and provide a correct statement for the benefit of everyone.
Sean Kearney (not verified)
on Jun 27, 2010
I'll throw my two cents in. I'm not a developer. I'm a Network Administrator but at the heart of it all, I'm a tech.

Yeah yeah, I sang a song or two about Powershell but I also understand confusion from other people at my level. Because it DOES just look like a Big Blue Command Prompt. I'm sorry guys, it DOES.

Having said that when you try some small pieces of Powershell, you start to understand some of the things that become incredibly easy. Add to it, you are NOT negated from using vbScript or Classic commands like NETSH with it.

My dip into Powershell was this. Client calls up and says "Erase all the logs in this folder older than 48 hours". Problem with a stupid vendor app.

I can't code vbScript (not well) and I didn't have a ready list of all the old stuff. It could be done with Delete with some trickery but this was a "NOW" answer. (You know those "NOW" answers where the client is breathing over your shoulder soon to be followed by an "OR ELSE")

A quick search online was a solution in Powershell. It took me a few minutes to test it on my system, about 15 to install it on the Server in Question and implement the solution. Still runs to this day.

I know where a lot of you are coming from. I'm an Admin too. I have about as much time to learn new Technology as I do to stop users from asking silly questions.

I use Powershell because it isn't too tricky. More importantly you'll find there is a huge community of people out here willing to help out. We KNOW what it's like with the boss breathing down your neck. I work in the Enterprise now but I was also that Small Biz tech who had to depend on solid reliable EASY to implement solutions.

Because it they weren't reliable and easy to implement, I'd be out of business the next day.

Syntax can be a little confusing in all languages. But don't be afraid to use the magic three words to wisdom "I Don't Understand" because let me tell you this, about a year ago...

That was me.



















ikkarus (not verified)
on Jun 27, 2010
I understand what the person is saying, and it does seem as if there are different powershell's. Like he said if you click on the default powershell icon you can not perform ad or exchange tasks. However with 15 - 20 minuets of research you can configure the shell to do whatever you want. When you run the exchange shell, it executes the same powershell as the icon you see under accessories. However the exchange shell loads the snapins needed for exchange tasks. Just like dos, or linux shells, powershell is very configurable, and you could configure it to load any snaping at any time. For example everytime I start my shell it loads the Quest AD snapin, and specop snapins. It was not hard to figure out how to do it. As a matter of fact I think it was Don that showed me in one of his classes.

Joel "Jaykul" Bennett (not verified)
on Jun 27, 2010
It's good to see that even with the strength of the "Windows IT Pro" brand behind your blogging efforts, there's always someone ready to call into question your authority and knowledge.

For what it's worth to put my 2c in, Don's correct. PowerShell can import as many modules and snapins simultaneously as you like ... and those "custom shells" are in essence just the regular PowerShell with a specific module/snapin pre-loaded. The functionality of the Exchange and AD shells in particular are certainly nothing more, despite the widespread misconception that their shells are somehow special.

One of the cool things about PowerShell remoting is that you can even import the commands from modules which are only installed on remote servers into your local PowerShell session -- so you don't even need the Exchange/AD/SQL modules all installed on the same box just to be able to combine them all in one script.



on Jun 28, 2010
Don and the other PowerShell fans, please, it shouldn't be so easy to accept that there is only one PowerShell.
Please try the Don's command "import-module ..." on a Windows 2008 Server. The shell will say "cmd not recognized". This command only works on Windows Server 2008 R2 and Windows 7. Then, there are different versions of PowerShell; the one with the 2008 R2-Windows 7 and the other with 2008-Vista.
As a result, you cannot use PowerShell to execute Exchange and AD related commands in the earlier versions. And how many of you do have only Windows Server 2008 R2? If you are running Exchange Server 2007, it can't be 2008 R2. If you are running Office Communications Server R2, it can't be 2008 R2. (This one being the most embarassing one for Microsoft).



x0n (not verified)
on Jun 27, 2010
@murat,

Don is correct: there is only *one* powershell. Yes, it's scary when you're staring at the blue console wondering where the "next" button is, but unfortunately not everything can be automated with a mouse. Powershell is a shell, designed to load multiple extensions and perform multiple tasks -- just like MMC, just like bash, just like CMD, just like Windows Explorer.

"When you want to do some Exchange related tasks you can't use the one that comes with the OS, you must use Exchange PowerShell. When you want to do some AD related task, say enable AD recycle bin, you must use PowerShell AD extension"

This is entirely incorrect. You *can* use the same shell that comes with the OS. As Don says, the "exchange shell" is just a shortcut to start up with the exchange extensions pre-loaded. You can use the standard shell and use "import-module" to load whatever extension you like - it's a two word phrase to load them. If I was to apply your thinking to Windows and its extensions (aka "Programs"), you're asking for Windows to have no task-oriented programs that must be started manually, instead Windows does EVERYTHING magically, so you can write documents, edit sound files, send emails, create spreadsheets, make music, etc etc using that single nebulous interface. Good luck with that.

There is a steep learning curve at first, but thankfully there is a strong community out there willing to share and help out, and Don is right up there with the best of them. Any time you invest in learning to shell script will pay you back ten fold, at least. Ask any sysadmins from the other side of the pond, gnu/linux, bsd, etc.









Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×