Moving from PowerShell Journeyman to PowerShell Master

I’ve just finished writing another book on PowerShell. The book looked at a number of core Windows Features and components, from AD, DHCP/DNS, SMB file sharing and FSRM, Hyper, V and more. Having gone through the process of witting over 125 scripts using a dozen Windows Server 2018 features  has given me a perspective on both PowerShell in use today, and in what it takes, what you really need to know in order to progress from a Google-Engineering assisted journey man into a PowerShell  master.  There is absolutely NOTHING wrong with using Google to get the job done. And for many their career path possibly precludes acquiring deep skills. But if you are the folks who aspire, please read on!

So what do you need to know, to know how to do? The following list is not in any order:

• Understand and be able to use the PowerShell language - the starting point, for me, is that you know the PowerShell language and can use it. You should understand the core concepts of cmdlets, objects, and the pipeline. You should be familiar the the core approach to discovery (Get-Module, Get-Command, Get-Help, and Get-Member). You need to know how each language feature works and be able to leverage it in your scripts. Knowing the internal architecture of PowerShell is also almost expected.
• Understand the .NET Framework. Powershell is built on top of .NET – cmdlets work by using .NET. Get-Process, for example, just calls [System.Diagnostics.Process]::GetProcesses(). Also known as a static method (GetProcesses()) on a .NET Class (Systems.Diagnostics.Process). You should understand the architecture of .NET (CLR, BCL, IL and JIT Compilation, .NET Security, and more).  The .NET Framework can often provide functionality for which there are no cmdlets. For example, there a number of .NET classes useful for localisation. Time zones, clock types, DST/ST, etc are all a method call away and therefore easy to use if you know how.
• Understand how to read C# and be able to convert C# to PowerShell. There is a feast of wonderful examples of more obscure tasks often written in C#. You should be able to read the C# sufficiently to see how the code is doing things, and be able to concert simple snippets into working PowerShell Code. Knowing enough VB.NET to convert it into PowerShell is also a useful skill.
• Understand COM and COM objects. There are a number of features that make use of COM. The Microsoft Office products can each be automated using PowerShell’s COM interop features. The Performance Logging and Alerting subsystem makes use of COM. You use PowerShell's New-Object cmdlet to instantiate a COM object to specify PLA data collector sets.
• Know how to use XML. Some features such as the Task Scheduler make use of XML. You should know how to use the XML emitted by windows as well as knowing how to manage XML documents and the DOM. XPath is also a useful skill. The FSRM, for example, produces reports. The report format is fixed and cannot be modified. But the FSRM also produces XML files containing the report’s raw data for you to format to your own needs. PowerShell also makes use of XML for default object formatting. which you can customise to change how PowerShell formats objects.
• Know how PowerShell modules work. Cmdlets are delivered in modules and you can write your own. Both DSC and JEA leverage modules. You should know where modules are stores, how PowerShell finds them and how it builds the Module cache, what a manifest is.
• JEA – Also known as Just Enough Administration. It’s a neat feature that enables you to provide delegated permissions to do just those things necessary for a person’s job and nothing more. This is a very useful security feature of Powershell that appeals to large and distributed organisations.
• Understand how to implement DSC. DSC is a great way to configure hosts and to ensure they stay configured. You should know about DSC resources, setting up DSC pull servers (SMB and Web), and DSC reporting and error logging. You should also know how DSC resources work as well as how to write your own DSC resources)
• Master Remoting – This is a rich topic area. You should understand the PowerShell Remoting stack (including PSRM, SOAP, WinRM), how end points work and how to create a constrained end point. 
• Understand at Depth Core Windows Features. I suppose it’s obvious, but to be a PowerShell master you have to be able to apply your skills  to Windows. You should really understand AD (and GPO), SMB (SMB3 SOFS, Clustering and Hyper-Converged S2D), Containers and Docker, Hyper-V (and maybe VMware too!), TCP/IP Networking, Disk/FIle Storage, PLA, Task Scheduler, and probably more.
• Leverage Azure – Organisations are increasingly moving to the cloud and knowing Azure (or AWS) is also an important skill. With Azure, you should be able to build IAAS objects in cloud including web sites, VMs, and Virtual networks. You should also be able to manage Azure Storage and Content distribution.
• Be competent at Windows Troubleshooting – There are a variety of good PowerShell tools that assist in Troubleshooting, particularly network troubleshooting. These tools really are second nature to a PowerShell master. And to be a good trouble-shooter you really need to understand what you are troubleshooting. Knowing how to leverage the information in the event logs is also critical. You should become very familiar with docs.Microsoft.com.  And if you ever work out how to fully automate the Windows trouble-shooters – let me know.
• Use PowerShell Core and VSCode – PowerShell Core 6 is almost a re-invention of PowerShell. Cross-platform, open source, based on .NET Core which is also open source along with a totally new development tool (VS Code). Arguably,6.1 and 6.2 are not quite ready for hard core usage across all features. But it’s close – I am now using the developing 6.2 and VS Code in preference to the ISE and Windows PowerShell. My Grateful Dead scripts even work in PS Core! There are a number of features that do not work with PowerShell Core. Today, for example, DSC and Windows Forms are not supported (although 6.3 should support Windows.Forms!).

So a baker’s dozen of things you really need to know, and know how to do with PowerShell.

Windows Server 2012/R2 Documentation-in PDF

Thanks to a post over on SpiceWorks, I’ve discovered that Microsoft has just published a full PDF of all the Windows Server 2012 and Windows Server 2012 R2 documentation. This represents the entire contents of the TechNet library on these two subjects. You can download from here: http://www.microsoft.com/en-gb/download/details.aspx?id=41182

Before you go rushing off to download – this is a big download. The pdf file itself is 110.9 MB. And definitely think hard before rushing off to print it out – it runs to 7970 pages. That’s around 8 reams of paper (or around 2 boxes). Not to mention the cost in toner!

Despite the size, this is a great document to have. I’ve loaded it onto my laptop and my Surface devices.

Technorati Tags: Windows,Documentation

Rob Menching and the MSI SDK

For Windows admins, the Windows Installer service has made life considerably easier. MSI packages are now far, far easier to install than what went before. IT Pros will know the value of using MSI packages with Group Policies and how to achieve it. In my training classes, it’s clear that some delegates know and love the concept but are less clued in on some of the details. A great way to learn more about how MS technologies work is to read the System Development Kit (SDK) documentation. SDKs are produced mainly for developer to help them understand how to program against a set of API, in this case how create MSI packages and how to use the Windows Installer service.

Over on Rob Menshing’s Open Uninstalled blog, I saw a post noting that the MSI SDK was not ranked very well in “major search engines”. That’s a shame as there’s a lot of good information here, including:

• The SDK Documentation (online) - http://msdn.microsoft.com/en-us/library/cc185688.aspx. Start from here and you can navigate to the other sections.
• The Windows Installer Documentation Roadmap - http://msdn.microsoft.com/en-us/library/aa371366(VS.85).aspx. This shows what documents exist and what they contain
• What’s new - http://msdn.microsoft.com/en-us/library/aa372796(VS.85).aspx. This is a series of pages explaining what’s new in each version, including versions 2.0, 3.0, 3.1, 4.0, and 4.5. Version 4.5 ships with Windows Server 2008 and Vista (and can be used on Win2k, Server 2003, and XP).
• Windows Installer Guide - http://msdn.microsoft.com/en-us/library/aa372845(VS.85).aspx. More information on aspects of the windows installer technology.
• Windows Installer Examples – http://msdn.microsoft.com/en-us/library/aa372837(VS.85).aspx. See it work!

There’s some great information here about the underpinnings of MSI packages and the Windows Installer service. It can help IT Pros understand more about how the technology works and will make them more comfortable. Rob’s blog is also a source of more information on both the Installer Technology and the WIX toolkit.

And hopefully, Robs and my blog articles will improve search ranking.

Technorati Tags: MSI,Windows Installer,Windows Installer Service,Windows

Why Exchange Server 2003 will not run on the x64-based versions of Windows Server 2003

I have become a real fan of Exchange 2007 - which may surprise some readers as I've previously been a non-fan. But with Exchange 2007, I'm finding that Microsoft has done something really pretty cool. Exchange 2007 is not a little mail system - it is an enterprise messaging solution (apologies for driving off into marketing speak, but the distinction is, IMHO, important.

At home, I've been running MailTraq, a nice SME mail server. It does mail as well as NNTP and also provides both mailing lists and web mail. Well I used to run Mailtraq - I now am running Exchange 2007 Beta 2 and it rocks.

One of the interesting features of Exchange 2007 is that, in production, it's 64-bit only. There are to be no 32-bit versions (for production), although for testing and training, Microsoft will provide a 32-bit version. This requirement is being made for a combination of performance and security. But in making the move, there are some backwards compatibility issues - not least of which is that Exchange Server 2003 will NOT run on 64-bit. Microsoft has issued an KB article, Why Exchange Server 2003 will not run on the x64-based versions of Windows Server 2003 to explain why. The answer, simply, is that Exchange 2007 installs a 32-bit IFS driver which for reasons not explained has not be recompiled into 64-bit (and is not signed). Thus it won't run on 64-bit Windows Server systems that require all drivers to be both native 64-bit and signed.