What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Microsoft System Center Powershell Essentials

Chapter 1. Setting up the Environment to Use PowerShell

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

Why use PowerShell?

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.

PowerShell version references

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 PowerShell 3.0
Windows Remote Management (WinRM) 3.0
Windows Management Instrumentation (WMI)
Management OData IIS Extensions
Server Manager CIM Provider

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.
Note
WMF 4.0 has the same set of OS requirement, but it needs Microsoft .Net Framework 4.5 as a prerequisite.

Setting up the System Center Configuration Manager environment

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

Connecting to Windows PowerShell for SCCM

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 Installation folder. For example, we will refer to the parent installation folder as C:\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 bin subfolder in the Configuration Manager Installation folder.
Now, import the ConfigurationManger.psd1 module file by using the Import-Module cmdlet:
```
PS C :\> Import-Module .\ConfigurationManager.psd1
```
Note
To confirm the successful import of the module, you can type Get-Module CMDLET in the PowerShell console. Now you will be able to see the new module added to the ConfigurationManager list.
After 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 ABC and two primary sites PS1 and PS2, then you can change the connection context like this:
```
PS C :\> Set-Location ABC:
PS C :\> Set-Location PS1:
PS C :\> Set-Location PS2:
```
Note
If you don't change the connection context, then you can't manage the Configuration Manager Site as well.
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

Connecting to Windows PowerShell from the SCCM console

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.

Setting up the System Center Service Manager environment

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

Connecting to Windows PowerShell for SCSM

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 PowerShell module, we need to change the console location to the Service Manager Console installation folder. For example, we will refer to the parent installation folder as C:\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 Manager subfolder in the Service Manager Console installation folder.
Import the System.Center.Service.Manager.psd1 module file for SCSM Management Servers by using the Import-Module cmdlet:
```
PS C :\> Import-Module .\System.Center.Service.Manager.psd1
```
Now you are ready to manage your Service Manager infrastructure for SCSM Management Servers using Windows PowerShell.
Import the Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1 module file for Data Warehouse Management Servers by using the Import-Module cmdlet:
```
PS C :\> Import-Module .\Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1
```
To confirm the successful import of the module, you can type the Get-Module cmdlet on the PowerShell console. Now you will be able to see the new module added to the System.Center.Service.Manager and Microsoft.EnterpriseManagement.Warehouse.Cmdlets lists.
Now you are ready to manage your Service Manager infrastructure for Data Warehouse Management Servers using Windows PowerShell.