Part I
Introduction
IN THIS PART
- Chapter 1 Introduction to Windows PowerShell
- Chapter 2 Whatâs New in Windows PowerShell V2
CHAPTER 1
Introduction to Windows PowerShell
IN THIS CHAPTER
- Managing Windows â the challenges of the past
- Introducing Windows PowerShell
- Understanding key Windows PowerShell concepts
- Discovering by leveraging the community
- Formatting with Windows PowerShell
- Automating administrative functions with scripting
- Extending Windows PowerShell with snap-ins and modules
- Installing Windows PowerShell
- Customizing Windows PowerShell with Profiles
Windows PowerShell is Microsoftâs strategic administrative task automation platform. It began life over 10 years ago and has now become mainstream. Before looking at all of the wonderful things that Windows PowerShell can do, this chapter starts by looking at how we got here, and then examining what Windows PowerShell is. This includes a brief overview of the language and syntax of Windows PowerShell.
Cross-Reference
The contents of this chapter mainly refer to Windows PowerShell Version 1. Version 2 added some great new features, and those are described more in Chapter 2, âWhatâs New in Windows PowerShell V2.â The features described in this chapter are all contained within Version 2, so everything you learn in this chapter is fully usable in Version 2.
Managing Windows â The Challenges of the Past
The path to Windows PowerShell has been a long but steady one that really started with the launch of the IBM PC in 1981. Since then management of systems has grown from something of a rarity to where we are today. This book starts by looking at where we have come from and the challenges that have arisen.
Management in the Early Days
Microsoft entered the PC operating system (OS) field in 1981, with the launch of the IBM PC. The original PC was a non-networked floppy diskâbased machine. Those who had more than one machine managed by carrying around floppy disks, copying them as needed. There was no hard disk to hold either programs or data. Subsequent versions of the DOS operating system added hard disk support, and eventually, there was local area networking capability.
The growth in corporate networks was greatly enhanced by the introduction of Windows. But management was more an afterthought than designed as a feature. This, of course, led to tools like Symantecâs Ghost to help to manage DOS and Windows systems. While the need to manage the systems was increasing, a number of architectural constraints of the older 16-bit architecture made this more difficult. And of course, at that time, Microsoft was not quite as focused on management as is the case today.
Management with Windows NT
The release of Windows NT 3.1 in the summer of 1993 marked a huge advance both in terms of the product and also the start of focusing on enterprise management. Not only was there a networking stack built in, but there was also a server version that enabled domains. In those days, most management tasks were conducted with GUI applications (for example, File Manager or User Manager). There was a rudimentary shell with a few commands, but coverage was far from complete.
Subsequent releases of NT (Windows NT 3.5 and 3.51) added features, but there was no real change in the overall management approaches within Windows NT itself. Microsoft was embarking on the creation of the Systems Management Server, but the creation of what we now know as System Center Configuration Manager took a number of years.
By the release of Windows 2000, some things had begun to change. Microsoft was pushing hard into the enterprise market where manageability was a prerequisite. As any Unix administrator would tell you, to manage large numbers of systems, you need automated scripting. To some degree, it felt like the mandate changed from âYou manage from the GUIâ to âYou manage from the GUI and the command line.â There was finally some acceptance that all those Unix guys had been right all along. But management was still very much piecemeal, with no overarching strategy or consistent toolset.
For Windows 2000, and more so for Windows Server 2003 and Windows XP, there was a push for command-line parity. If you can do something from the GUI, you should be able to do it from the command line. This led to a plethora of command-line tools from each different product group and subgroup. This change was highly welcome, of course, but not without challenges. None of the tools resembled any of the other tools, so what you learned about one was definitely not transferrable.
Management with Windows Server 2003
During the Windows 2003 days, things continued on â much as with Windows 2000 â but with improved feature parity between the command line and GUI. There were really no fundamental changes in the approach to managing Windows desktop and server systems, at least for public consumption.
By the time Microsoft released XP and Windows Server 2003, the very earliest version of Windows PowerShell, or Monad as it was then called, had begun to surface. But Monad wasnât really enterprise-ready. Some groups within Microsoft began talking up this new approach, but the mainstream audiences were not taking much heed at that point.
Another key aspect of managing this generation of systems was the huge number of Group Policies added into the client OS (XP). Microsoft also beefed up the Windows Management Instrumentation (WMI) components, although to some degree, this was probably more useful to folks writing management tools than to IT professionals.
During this time period, Microsoft was pushing Systems Management Server (SMS, later to be renamed System Center Configuration Manager), which was homegrown, as well as Microsoft Operations Manager (renamed later to System Center Operations Manager), which Microsoft acquired from a purchase. However, in those days, the individual products (that is, Operations Manager and SMS) were very distinct and separate products. The package we now recognize as Systems Center, and the other members of the family, were still some years off.
Introducing Windows PowerShell
To some degree, the death knell of the Management By GUI age was the publication of the Monad Manifesto in August 2002. You can download this document from http://blogs.msdn.com/b/powershell/archive/2007/03/19/monad-manifesto-the-origin-of-windows-powershell.aspx.
The manifesto suggested that the key issue was the lack of âadministrator-oriented composable tools to type commands and automate management,â which were the domain of scripting languages. The main scripting tools of the day, however, worked by using âvery low level abstractions such as complex object models, schemas and APIs.â
The paper goes on to suggest a broad architecture of components. Though a lot of details have changed since that document was written, Windows PowerShell today delivers on the promise.
A year later, in September 2003, Microsoft demonstrated Monad in public for the first time at the Professional Developers Conference. Though it took a number of years to get from Monad to where Windows PowerShell is today, the result has made the journey worthwhile.
What Is Windows PowerShell?
Before you begin to use Windows PowerShell, you must understand a bit about it. This section takes a look at what Windows PowerShell is and what it contains.
Windows PowerShell as a Task Automation Platform
Windows PowerShell is, first and foremost, Microsoftâs strategic administrative task automation platform. It aims to help the administrator, the IT professional, to manage all aspects of a Windows system and the applications that run on them as efficiently as possible, both locally and remotely...