Why isn't there a PowerShell MS certification?

N2IT

Will there be one in the future? My whole department is consistently using PS to script. It's one of the most useful tools we have here in our department. I figured since it's so popular that it would have a certification backing it.

You can't even be considered for a SA role here if you can't use PS.

ptilsen

Because PowerShell is just a tool, and an easy one to use. If you can program, you can use PowerShell. If you can script in vbscript or shell code you can script in PowerShell. Even if you really have no coding background and aren't knowledgeable on programming theory and conventions, almost anyone can Google and get by doing basic tasks. The reason no PS-specific certification exists lie in its simplicity, limited applicability, ease-of-use, and the fact that anyone with a computer science degree or scripting experience can reasonably use it.

However, PowerShell and scripting in general should be a larger component of MS infrastructure certifications. I'm not aware of any certification that makes you show you know what WMI is and what can be done with it, and that needs to be part of some Windows certification. PowerShell probably should be as well.

Slowhand

They have an MCTS exam on Windows Internals, so why not a stand-alone MS exam on PowerShell? Well, perhaps it's because no one knows or cares about the 70-660 test, they just learn to use the Windows SysInternals tools to help them in their jobs. Details, details. . .

Perhaps as a developer exam, or if there was a larger focus on writing "bigger" scrips with PowerShell, but those topics would be wrapped up in other exams that cover tools to do that job; SCCM being a great example of the kind of tool that already automates a lot of the functions you could script in PowerShell, as well as one that can be automated with PowerShell. I, for one, would rather see more expanded testing of PowerShell skills in the existing technology exams, since it's a tool that augments Microsoft products, as ptilsen said.

ptilsen

So, I had never heard of that particular certification. I did not think there existed an MS cert relevant to my interests of which I was unaware. I would take it in a heartbeat if I thought any employer would ever care about it.

MS needs to make that part of an MCSE level certification. Seriously. That is awesome stuff. I feel there is a lot of general Windows knowledge missing from that and all other certs, though, that MS doesn't include in the appropriate tracks.

Slowhand

Would be nice if they had an "understanding the Windows kernel" kind of exam too, wouldn't it? Hell, they could revamp that Internals exam to include an in-depth look at the modern Windows kernel, how it relates to and is affected by the likes of local policy and Group Policy, as well as how to work on a deeper level with Windows using the Sysinternals tools, PowerShell, etc. I'd be first in line to take a crack at THAT exam.

ptilsen

Yes. There is a big disconnect, IMO, on the emphasis of the major infrastructure certifications and actually working as a Windows IT professional. There needs to be exams on the operating system itself. The client certs in particular make no sense. They are about deploying those operating systems across many systems in large enterprises, not about the operating system in and of itself.

N2IT

Isn't Lync just a tool as well and PowerPoint? They have exams for those. Heck they have exams for HTML5 and CSS3, VB.net, C#, etc.

I think your point has merit but should include some certifications that are already in production as well. I think most of the MS certifications are silly, most of the knowledge you can learn performing the position and researching on your own. (I'll stop there and not go down that road any farther).

AS PT mentioned most CS majors have no trouble scripting. That's why where I work won't touch an admin unless they have a CS degree or strong scripting and automation. If you can't automate you really don't belong in our environment, at least that's what they are preaching.

ptilsen

The Lync certification is on the deployment of Lync. There isn't an exam just for the client. You don't really see too much demand for programming certs, and PowerShell is not a full-blown programming language.

I agree to an extend that most of what's on MS certifications can be learned from self-study, but the whole point is to verify that the information is there. I would still prefer to work with certified people because they've proven knowledge.

That brings me to another issue, which is that programming is hard to put into the usual test format. I don't know how they do it for the .NET certs, but if it's pure multiple choice it's going to be lacking. And the reason you don't see as much demand for programming certs as infrastructure is one certification cannot replace what's learned in a computer science degree, and all the pieces need to fit. It would be a ridiculous 12-hour exam to make sure they're their with a cert.

What I do think would be cool would be something similar to that Windows Internals certification. It should be about kernel stuff, WMI, services, drivers, the registry, policy, and command-line with PowerShell and CMD. Too much of the deeper Windows stuff is only on higher-level server certs and even there, too much of it is lost in the "how do I complete X task" nature of it, rather than "how does X work." The problem you posit about MS certs is they're about how to do things (almost always easily Googled) vs. how things work (not as easy and meaningful to Google). I could see PowerShell being a big part (maybe 10% or 20%) of this cert. I just don't see it being its own cert. When you've programmed in lower-level languages or scripted in others, you understand that scripting in one language doesn't merit a full TS-level Microsoft certification, but could definitely be a good part of a larger cert.

antielvis

Well you can take a certification for Outlook, Word, etc, so why not Powershell? And it's MS that is pushing SA's to use Powershell so why not some form of certification?

OT a bit, but I find the whole MS command line/scriptings stuff maddening. It is perpetually changing. Their command line stuff (they wanted us to use it on Server Core) is horrible. Bash/Linux puts MS to shame.

ptilsen

antielvis wrote: »

OT a bit, but I find the whole MS command line/scriptings stuff maddening. It is perpetually changing. Their command line stuff (they wanted us to use it on Server Core) is horrible. Bash/Linux puts MS to shame.

I don't see where this is coming from. CMD was almost entirely unchanged for over a decade. Most of what's there now was in the 9x kernels' DOS, and probably pre-Windows DOS. A few commands went deprecated, but probably no more than on the Linux side of things. VBscript was arguably the standard for more advanced scripting for a decade and also went unchanged. PowerShell is new, true, but it was created to bridge the gap between what CMD/VBscript and BASH & Python could do and how easily (BASH > VBScript, no question). PowerShell is actually more powerful than BASH, arguably even Python, and definitely easier to read and write than BASH. To N2's point, it actually is powerful enough to act as substitute for VB .NET or C# .NET, but I don't see anyone realistically using it over a compiled language for software development.

PowerShell hasn't dropped, deprecated, or changed syntax on any cmdlets since its inception, AFAIK. Each version adds new cmdlets, but those are improvements that have no downside, not change in any negative connotation. MS looks at what systems people are doing and says "hey, let's just make a cmdlet so 10,000 people don't have to Google, copy, and adjust something we could easily integrate."

I'm really not sure what changes you're unhappy with. In ten years, nothing I've been doing in Windows shell scripting and VBscripting has changed drastically outside of improvements and additions. The biggest example that comes to mind is cacls being deprecated and xcacls disappearing for icacls to replace them, and I've yet to hear anyone complain about it. I don't think wscript and cscripts interpretation of VBScript have changed at all. While kernel changes will make old API calls occasionally go bad, WMI calls generally work in VBScript across Windows versions. Heck, most of the scripts I use for SCCM 2007 R2 SP3 are from SMS 2003 and will still work after I upgrade to System Center 2012. Even with all the System Center Changes over the last ten years, almost every script I've ever needed was written be someone else in 2003 and still works. Some were ported to PowerShell just for slight enhancements and fun, too.

The Office suite is actually pretty deep, and there are lots of considerations to deploying it and plenty to learn to use it effectively. PowerShell itself (like BASH) is not very deep, and any programmer can pick it up very quickly. The programming conventions and understanding of WMI, the API, the kernel, and other components that going into being great at scripting and programming in Windows are deep -- too deep for a "powershell" certification, but maybe good for a Windows Internals certification (which could include PowerShell).

antielvis

@ptilsen:

Perhaps it's because I spent time as a Linux admin, but I find the MS CLI more clunky than I do BASH. A good example is DSADD. When I saw the syntax for that years back, I couldn't imagine anyone trying to learn it to add a user. Little has changed with Powershell but I dont' understand the point of having to install modules. It seems unintuitive at the least. You certainly don't do that in Linux nor in CISCO.

And yes, you are correct when you say Powershell, like BASH, is not that deep. What you're forgetting is that in Linux the SysAdm is accustomed to admin'ing in text. This is not the case for most Windows Server admins. In fact, a good majority of Windows server guys can't even write scripts.

Iv'e been reading up on Windows Server 2012. I find it odd that MS is now promoting Powershell as the de facto method to administrate Windows Server. I just don't believe that it's going to catch on. And I believe that the absymal flop which was "Server Core" failed because of the same reason. Most people look at that CLI box and think "now what?"

If MS expects SysAdm's to use Powershell as the preferred method of administration, then it should be covered in detail in the MCSA/E.

ptilsen

antielvis wrote: »

@ptilsen:

Perhaps it's because I spent time as a Linux admin, but I find the MS CLI more clunky than I do BASH. A good example is DSADD. When I saw the syntax for that years back, I couldn't imagine anyone trying to learn it to add a user.

No disagreements here. I've never found myself wanting to use DSADD. But, it's better than nothing. The Windows command line is definitely clunkier than BASH. I don't think anyone with serious experience in both would dispute that. And that's why PowerShell was created.

antielvis wrote: »

Little has changed with Powershell but I dont' understand the point of having to install modules. It seems unintuitive at the least. You certainly don't do that in Linux nor in CISCO.

I think lots has changed with PowerShell. The need to import standard modules is silly, I agree, but so does MS (no longer need to in PS 3.0). However, the point of modules is that PowerShell is modular. It can be used to administer other components -- Exchange, SharePoint, System Center -- with modules. I don't see it as any less intuitive than things are done in Linux -- just different. Again, this in contrast with old-school DOS and command prompt, which were limited and unintuitive (though still quite usable). Modules are a feature, in the not-ironic sense of the word. Think of it this way: On Linux, to administer MySQL or Apache, you would edit the config file or run mysqld or httpd. In Windows, the direction is you use the PowerShell cmdlet and module.

antielvis wrote: »

And yes, you are correct when you say Powershell, like BASH, is not that deep. What you're forgetting is that in Linux the SysAdm is accustomed to admin'ing in text. This is not the case for most Windows Server admins. In fact, a good majority of Windows server guys can't even write scripts.

Again, you'll get no disagreement here. And again, this is where PowerShell comes in. Everything gets done in UNIX style string management in PowerShell. The registry, WMI, Active Directory all get displayed and manipulated as textual hierarchies in PowerShell, and frankly I think it's way better than how things are done in BASH on Linux. I can write a script to perform a recursive file system task, and easily modify it to do something in the registry, AD, WMI, whatever. I don't need a different executable or text file. I just need a different cmdlet, and the cmdlets arguments are so similar I can often use a new one without looking at the help page for more than a minute. You need to also consider that PowerShell was designed FUBU -- For UNIX-programmers by UNIX-programmers. Many commands are aliased to BASH/UNIX/Gnu equivalents, and syntax is functionally similar. Again, no disagreement that BASH is way better than command-line. PowerShell was created to address that. Windows admins will need to learn and recognize the utility of this or become obsolete.

antielvis wrote: »

Iv'e been reading up on Windows Server 2012. I find it odd that MS is now promoting Powershell as the de facto method to administrate Windows Server. I just don't believe that it's going to catch on. And I believe that the absymal flop which was "Server Core" failed because of the same reason. Most people look at that CLI box and think "now what?"

I agree to an extent. With the direction things are going, being a Windows admin is actually going to be more difficult. By that, I don't mean that tasks become harder. In fact, doing anything outside of the GUI is becoming easier. However, the bar is raised. Almost any moron can at least fake it in Windows with the intuitive GUI and Google. Scripting is becoming a bigger part of things, and the need for button-clickers is going away.

The problem with server core was limited benefit. Even Linux servers (AFAIK, admittedly) usually have GUIs. GUIs aren't a bad thing, and even with single-core virtual systems the resources to use Explorer and Server manager are not so high as to justify using server core in most scenarios. Only in the even that mass automated server configuration is being done does it make any sense, and even that is generally done with SCCM rather than configuration scripts. What MS is trying to do is combine great GUI management with great scripting and automation capabilities. I think they're doing a good job, but I do think there could be some more consistency and direction. On a somewhat related note, Windows needs to recognize .PS1 files the way it recognizes batch files. It may seem a trivial complaint, but having to constantly call PowerShell rather than it being the console hurts its adoption and usefulness.

antielvis wrote: »

If MS expects SysAdm's to use Powershell as the preferred method of administration, then it should be covered in detail in the MCSA/E.

Here I agree completely. As I've been saying, a Windows internals certification or two should be a part of MCSA and MCSE, and scripting (primarily in PowerShell) should be an entire topic. I still don't think PowerShell needs its own cert any more than BASH does. It needs to be part and parcel of the OS and basic administration of it.

Claymoore

Want a PoSh exam? Go take an Exchange test. The 236 exam for Exchange 2007 was half PoSh, half Exchange. Problem was, the questions were pedantic with two identical commands except one used get-mailuser and the other get-mailusers, for example. It's PowerShell - it's not like we cut the red wire instead of the blue wire. The later version exams had less Powershell on them, but it's still there. I had some beta questions where you drag and drop lines of commands to create a full script, as opposed to a single syntax question, and I liked the new format.

I have been using PowerShell since I started using Exchange 2007, but nothing I do is complicated. My scripts are maybe 8 lines at most. Lots of what I do is just a single command line with a pipe or two. I don't see any way to build an exam that can assess the work process of single command lines that would not wind up being a pure cmdlet memorization exercise. There is no dedicated Windows security exam any more because security is part of every exam. I see PoSh being the same way - a PoSh question or two in every exam rather than its own, dedicated exam.

Claymoore

antielvis wrote: »

Iv'e been reading up on Windows Server 2012. I find it odd that MS is now promoting Powershell as the de facto method to administrate Windows Server. I just don't believe that it's going to catch on. And I believe that the absymal flop which was "Server Core" failed because of the same reason. Most people look at that CLI box and think "now what?"

Imagine being an Exchange admin 6 years ago and having PoSh dumped on you as the ONLY way to administer certain features, like Public Folders. Then, just as you get comfortable on the command line, you learn that powershell can't do some things like AD administration. Luckily, it's extensible, so Quest and other companies created modules that added the missing functionality. I'm happy MS is standardizing on PoSh because the command structure will now be the same across the product lines. Now we just need more native PoSh cmdlets instead of having to use other commands, like NetSh, or digging into WMI.

antielvis

@Ptilsen

Thanks for an engaging debate on a topic none of us talk about enough. Personally I hope MS embraces PS because I think it's good for MS & it's also good for those of us who admin MS. I was around in the 90s and got the MCSE 4. At first it was a ticket to a job. A few years later every Tom, Dick and Forklift Driver had it. It completely discredited those in IT and lowered the bar. I like seeing MS raise the bar...this industry needs it so we can finally get the credit (and appreciation) we deserve. This is a complex industry.

I guess what most frustrates me about MS is how inconsistent things are. Yes, Powershell is rather nice, but then take DSADD. You'd think that the command for ADDING A USER might not require 120 keystrokes? I hope they stick with PS and build on it & deprecate everything else.

@Claymoore. Yeah, I remember Exchange 2007. It was a crash course in Powershell. Classic MS, changing something without consulting the market. Reminds me of them removing the Start Button. I've yet to meet anyone that says "what a brilliant idea". Ya noticed in 2010 how PS became less important..lol.

ptilsen

PowerShell has gotten pretty good, but I'll admit they haven't replaced all the old tools. DSADD and AD are the best example. Look at all the sweet cmdlets:
Active Directory Cmdlets in Windows PowerShell
The elephant not in the room is Add-ADUser/Add-ADComputer/ADD-ADAccount. One or more of those need to be made, because DSADD or an actual PS script are monstrous alternatives to what a good cmdlet could make a pleasant task. And admittedly, even today a lot of what I do with PowerShell is use it to call other tools, and the paradigm isn't quite consistent. If you even need to call Robocopy, for example, you'll find just passing arguments in a PoSh script to be really un-intuitive (hint: you can't just build the string and call it with Robocopy even the same way you can in a PowerShell window). What I hope to see MS do is make command and executable currently available aliased to a cmdlet. It is maddening that Copy-item is aliased to copy but if you want Robocopy or xcopy, you have to call them, usually with cmd /c or invoke-expression just to get the args right.

I will also say that the explanation pages on some Cmdlets are really bad, forcing most people to go to an old-school tool to get what should be a simple task done. Want to set ACLs with a PowerShell cmdlet? Good luck. Calling icacls or even deprecated cacls is way easier than even reading the man page. Set-Acl is actually way more powerful than those utilities, but self-defeating by its own difficulty.

So, PowerShell isn't perfect. MS needs to get the paradigm consistent, with more aliasing and clearer, better-documented arguments and examples. However, I love it. I think it's great. If they keep going this direction, Windows will become a more manageable platform while simultaneous raising the bar on who can pass as a competent engineer.