Welcome! In this introductory chapter, we will throw some light on how the idea for this book came in to our minds. Here, we will cover topics that can help users perform various routine tasks in the System Center environment by using legacy consoles. A decade back, an administrator had to go with legacy Microsoft Management Consoles, broadly known as MMC, for most of the Microsoft products. Now, with the changes in the architecture of the Microsoft products and the birth of automation engines such as Windows PowerShell, automation has become easy; however, many of us are not fully aware of it. Let's start with setting up the environment.
In this chapter, we will cover:
The purpose of this book
The target audience
Why use PowerShell?
PowerShell version references
Setting up the System Center Configuration Manager environment
Setting up the System Center Operations Manager environment
Setting up the System Center Service Manager environment
This book will help you to achieve the idea of automation, especially in the System Center environment using Windows PowerShell. The purpose of this book is to provide you with an insight of various PowerShell techniques that can be applied to the following three System Center products:
System Center Configuration Manager (SCCM)
System Center Operations Manager (SCOM)
System Center Service Manager (SCSM)
We will also highlight how to use the various PowerShell cmdlets available with these three product SDKs, along with their key tips and tricks. All guidance and assistance will be provided to you on a high-level basis. Further exploration and hands-on experience for these three products is required, so that you gain the most out of this book.
This book is aimed mainly at IT professionals who maintain or perform routine activities in the System Center environment focusing on SCCM, SCOM, and SCSM products. This book will be very useful for people who seek out-of-the-box automation for their System Center infrastructure, using Windows PowerShell. You will find real time use of Windows PowerShell with these System Center products.
In the last few years, the scripting world has witnessed a number of changes. We can hardly recall the time when people used ancient mainframe machines with green-colored text and dark, black-screen backgrounds. Times have changed and we are living in a world where technological adoption is quicker than ever.
Nowadays, an ample number of scripting languages exist, which fulfill the needs of an administrator. One of the questions that arise in one's mind is: why should we go with Windows PowerShell? There are reasons why we prefer Windows PowerShell over other scripting languages. To answer the preceding question precisely, we would rather put a counter question in front of you: give us a valid reason why we shouldn't go with Windows PowerShell.
There are other examples of strong scripting languages, such as VBScript, Ruby, Python, Perl, and so on, and administrators have adopted them too. VBScript became popular because of the automation of routine, local administrator tasks, but the code was a bit complex and hard to understand for novice users. Looking at Windows PowerShell, we feel that the Microsoft team has worked hard to give us a powerful, interactive scripting shell with an object-driven approach.
The important and exciting thing about this language is that it's a spitted object-based output, which can be reused easily. It has pipeline and PSRemoting as its crucial features, which put this language as the first priority while comparing it with other scripting languages. Moreover, by following the Common Engineering Criteria (CEC), Microsoft has decided that all future Microsoft products will come with extensive Windows PowerShell support. This is also a good reason to learn and choose Windows PowerShell. Additionally, PowerShell can be leveraged to use the massive .Net Framework class functionality with most of the Microsoft products. We can also achieve inventory and reporting by efficiently using the WMI functionality that lies within PowerShell. A few Microsoft products support extensive functionality when used with PowerShell; the best example is Exchange Server.
In this section, we shall talk about the various versions of Windows PowerShell that are available and we will share a few notes on the latest versions v3.0 and v4.0, along with their preinstallation requirements and dependencies.
So far, we have had four stable versions available for Windows PowerShell. Windows PowerShell v1.0 was an extension of Command Prompt with a limited number of cmdlets. In the second version, the team introduced pipeline and PSRemoting concepts, which made Windows PowerShell a popular scripting shell. Furthermore, with the release of Windows Server 2012 and Windows 8, Windows PowerShell version 3.0 was a drastic improvement in terms of the number of cmdlets and modules. They have also introduced the Windows PowerShell Web Access (PWA), PowerShell Workflows, and Scheduled Jobs concept in this version. The exciting part is that while we were drafting this book, the Microsoft team was coming up with its next release of operating systems, named Windows Server 2012 R2 and Windows 8.1. In this release, they have introduced Windows PowerShell v4.0 embedded with extensive functionality, such as Desired State Configuration (DSC) and so on.
Note
While we are in the process of publishing this book, the PowerShell team has already come up with the preview release of Windows PowerShell 5.0 with some extensive functionality.
By default, Windows PowerShell 3.0 comes up with Windows Server 2012 and Windows 8. There are a number of default modules present in this version. If you are running an operating system lower than the ones specified in the preceding section, you need to manually install Windows Management Framework 3.0, which is also known as WMF 3.0.
Note
If you have installed any previous releases of Windows Management Framework, you must uninstall them before installing Windows Management Framework 3.0.
Windows Management Framework 3.0 can be installed only on the following operating system versions:
Windows 7 SP1
Windows Server 2008 R2 SP1 (WMF 3.0 is also supported if you are running Windows Server 2008 R2 as the server core)
Windows Server 2008 SP2
Windows PowerShell 2.0 is embedded in the Windows Server 2008 R2 and Windows 7 operating system. You don't need to separately install it on these operating systems.
The contentions written here use the latest version of PowerShell (v 4.0). However, most of the cmdlets are also supported in the legacy version, as well. As a minimum, you need to have PowerShell 2.0 in your machine; however, it would be best to have the latest version of PowerShell. You can refer to the TechNet link (https://technet.microsoft.com/en-us/library/hh847769.aspx) for detailed information on the prerequisites for different versions of PowerShell.
Windows Management Framework 3.0 is available for all supported versions of Windows in the following languages: English, Chinese (simplified), Chinese (traditional), French, German, Italian, Japanese, Korean, Portuguese (Brazil), Russian, and Spanish.
Windows Management Framework 3.0 contains:
Windows Management Framework 3.0 requires the following software to be installed prior to the WMF 3.0 installation:
Microsoft .Net Framework 4.0: You can install Microsoft .Net Framework at http://go.microsoft.com/fwlink/?LinkID=212547
Windows 7 Service Pack 1 on computers running Windows 7: To install SP1, go to http://www.microsoft.com/en-in/download/details.aspx?id=5842
Windows Server 2008 R2 Service Pack 1 on computers running Windows Server 2008 R2: To install SP1, go to http://www.microsoft.com/en-in/download/details.aspx?id=5842
Windows Server 2008 Service Pack 2 on computers running Windows Server 2008: To install SP2, go to http://www.microsoft.com/en-in/download/details.aspx?id=16468
In addition to the preceding software, you will need to meet the following requirements:
To install Windows PowerShell Integrated Scripting Environment (ISE) for Windows PowerShell 3.0 on computers running Windows Server 2008 R2 with Service Pack 1, use Server Manager to add the optional Windows PowerShell ISE feature to Windows PowerShell before installing WMF 3.0.
Install the latest updates before installing WMF 3.0.
This section talks about how to setup your Windows PowerShell console to start with the SCCM activities. The traditional method of importing the SCCM module in Windows PowerShell is supported by SCCM 2007 and its later versions.
The prerequisites to set up SCCM are as follows:
SCCM 2007 or its later version infrastructure
Windows PowerShell 2.0 or its later version
The steps for connecting to Windows PowerShell for SCCM are as follows:
Start the 32-bit Windows PowerShell console from your operating system box, as the SCCM infrastructure is only supported with the 32-bit PowerShell architecture.
If you are using Windows Server 2008 R2 or a similar operating system, then you can click on Start, search for Windows PowerShell (x86), and launch the console.
If you are using Windows Server 2012 or a similar operating system, then you can press the Windows key + F, search for Windows PowerShell, and choose Apps in the console. From the search list, select Windows PowerShell (x86) and launch the console.
To import the Configuration Manager PowerShell module, we need to change the console location to the
Configuration Manager Installationfolder. For example, we will refer to the parent installation folder asC:\Program Files(x86).Type the following lines into the PowerShell console:
PS C :\> cd "C:\Program Files(x86)\Microsoft Configuration Manager\AdminConsole\bin"This will set the console location to the
binsubfolder in theConfiguration Manager Installationfolder.Now, import the
ConfigurationManger.psd1module file by using theImport-Modulecmdlet:PS C :\> Import-Module .\ConfigurationManager.psd1After successfully importing the module file, set the console location to your site location by using your site code. For example, we have taken ABC site code in the following command statement:
PS C :\> Set-Location ABC:The Configuration Manager PowerShell module also includes PowerShell Driver Provider for Configuration Manager Sites. For example, if you have a central site administration, site
ABCand two primary sitesPS1andPS2, then you can change the connection context like this:PS C :\> Set-Location ABC: PS C :\> Set-Location PS1: PS C :\> Set-Location PS2:
Now you are ready to manage your Configuration Manager infrastructure using Windows PowerShell.
Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
There is also another simple method available to connect SCCM using PowerShell with the latest releases of SCCM 2012 and so on. The prerequisites for that are as follows:
System Center Configuration Manager 2012 SP1 RTM or a later version infrastructure
Windows Server 2012 or Windows Server 2008 R2 with WMF 3.0
The steps for connecting to Windows PowerShell from the SCCM console are as follows:
Press the Windows key + F, search for Configuration Manager, and choose Apps. From the search list, select Configuration Manager Console and launch the console.
In the Configuration Manager Console, click on the upper-left corner of the console and select Connect via Windows PowerShell.
The Configuration Manager then imports the PowerShell module automatically.
Now you are ready to manage your Configuration Manager infrastructure using the Windows PowerShell console.
This section discusses how to set up your PowerShell console to start with the SCOM activities. The traditional method of importing the SCOM module in Windows PowerShell is supported by SCOM 2012 and its later versions.
The prerequisites for this are as follows:
SCOM 2012 or the later version infrastructure
Windows PowerShell 2.0 or its later version
The steps for connecting to Windows PowerShell for SCOM are as follows:
Start the 32-bit Windows PowerShell console from your operating system box.
If you are using Windows Server 2008 R2 or a similar operating system, then you can click on Start, search for Windows PowerShell (x86), and launch the console.
If you are using Windows Server 2012 or a similar operating system, then you can press the Windows key + F, search for Windows PowerShell, and choose Apps. From the search list, select Windows PowerShell (x86) and launch the console.
To import the
Operations Manager PowerShellmodule, we need to change the console location to theOperations Manager Console installationfolder. For example, we will refer to the parent installation folder asC:\Program Files(x86).Type the following lines into the PowerShell console:
PS C :\> cd 'C:\Program Files\System Center 2012\Operations Manager\PowerShell\'This will set the console location to the
PowerShellsubfolder in theOperations Manager Consoleinstallation folder.Now, import the
OperationsManger.psd1module file by using theImport-Modulecmdlet:PS C :\> Import-Module .\OperationsManager.psd1Now you are ready to manage your Operations Manager infrastructure, using the Windows PowerShell console.
In this section, we will talk about how to set up your PowerShell console to start with the SCSM activities. The traditional method of importing the SCSM module in Windows PowerShell is supported by SCSM 2010 and its later versions.
Here are the prerequisites to set up the SCSM environment:
SCSM 2010 or its later version infrastructure
Windows PowerShell 2.0 or its later version
Start the Windows PowerShell console from your operating system box.
If you are using Windows Server 2008 R2 or a similar operating system, then you can click on Start, search for Windows PowerShell (x86), and launch the console.
If you are using Windows Server 2012 or a similar operating system, then you can press the Windows key + F, search for Windows PowerShell, and choose Apps. From the search list, select Windows PowerShell (x86) to launch the console.
To import the
Service Manager PowerShellmodule, we need to change the console location to theService Manager Console installationfolder. For example, we will refer to the parent installation folder asC:\Program Files(x86).Type the following lines into the PowerShell console:
PS C :\> cd 'C:\Program Files\Microsoft System Center 2012\Service Manager\'This will set the console location to the
Service Managersubfolder in theService Manager Console installationfolder.Import the
System.Center.Service.Manager.psd1module file for SCSM Management Servers by using theImport-Modulecmdlet:PS C :\> Import-Module .\System.Center.Service.Manager.psd1Now you are ready to manage your Service Manager infrastructure for SCSM Management Servers using Windows PowerShell.
Import the
Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1module file for Data Warehouse Management Servers by using theImport-Modulecmdlet:PS C :\> Import-Module .\Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1To confirm the successful import of the module, you can type the
Get-Modulecmdlet on the PowerShell console. Now you will be able to see the new module added to theSystem.Center.Service.ManagerandMicrosoft.EnterpriseManagement.Warehouse.Cmdletslists.Now you are ready to manage your Service Manager infrastructure for Data Warehouse Management Servers using Windows PowerShell.
By end of this introductory chapter, you should be able to understand the basic terminology and setup requirement to use Windows PowerShell with several System Center products.
Going ahead, we will specifically look at each of these products and try to explore more functionalities that we can achieve using Windows PowerShell.
