Now that you've seen how to get output from a cmdlet, let's look at that output in more detail.
First, and possibly most importantly, PowerShell treats darn near everything as an object. Even simple bits of information such as text or dates are actually Integer and DateTime objects to PowerShell (as they are defined in the .NET Framework). Treating text and dates as objects may seem like overkill, but it gives you advantages that aren't visible on the surface. Let's look at some examples in the following code:
SmyValue = "This is a text string"
$myVa1ue.GetType() # String object
SmyValue.Length # length of the string
$myVa1ue.SubString(10,4) # extract 4 characters
# starting at position 10 $myVa1ue.Rep1ace(" ","-") # replace spaces with dashes $myVa1ue.Sp1it(" ") # 4th word in the string
ScurrentTime = [DateTime]::Now
# get the current time $currentTime.GetType() # DateTime object $currentTime.AddHours(4) # add 4 hours to the time $currentTime.DayOfWeek # display day of the week $currentTime.Hour # display the hour value $currentTime.IsDay1ightSavingsTime()
# is daylight savings in
$currentTime.ToString # format the date and time
(New-TimeSpan $(Get-Date) $currentTime).Minutes
# how many minutes have
The commands presented in this code are really just parlor tricks with a few of the simple object types available in the .NET Framework, but they should give you some ideas about how powerful objects (even really simple ones) can be!
PowerShell mastery is a long and arduous journey, and I think the only people to truly achieve enlightenment are those who were on the team that developed it. Luckily they've given us some guide books. To that end I suggest you read Bruce Payette's book Windows PowerShell in Action or Lee Holmes's Windows PowerShell Cookbook. Or both!
By this point you might have noticed we haven't seen any cmdlets that really have anything to do with Active Directory. There's a reason for that: there are none. At least not yet.
In the development cycle of recent Microsoft products (such as Windows Server 2008), PowerShell was actually a latecomer to the build. With Microsoft's PowerShell push in the Exchange Server and Operations Manager Server products, it was a natural decision for Microsoft to include PowerShell with Windows Server 2008, but the developers didn't have time to create any cmdlets specifically for managing Active Directory.
But thanks to the folks at Quest Software, that doesn't mean we're up a creek. They were kind enough to write a set of Active Directory Management cmdlets and make them freely available on the Web. Open your web browser and navigate to the following URL to download and install the Management Shell for Active Directory: www.quest.com/activeroles-server/arms.aspx. While you are there be sure to download the Administrator's Guide too!
Installing the Management Shell for Active Directory makes a PowerShell snap-in available. A snap-in is basically a bundle of PowerShell functionality, usually specific to a task or server product, that we can incorporate into our PowerShell session as needed. However snap-ins are not loaded by default so we need to execute the following command to get access to the new set of cmdlets:
To make the cmdlets available for all system users we can simply place this command in the system profile, which we'll talk about next.
Old-timers among us will remember the name autoexec.bat—the batch file that ran whenever we started the system and it was used to (among other things) set up the environment to our own tastes. We can do something similar with profiles in PowerShell.
A profile is simply a text file named profile.psl residing in one of the special locations known to PowerShell. These profiles are PowerShell scripts that execute each time the PowerShell environment starts. To keep things simple we'll talk about the two most obvious profiles: your personal profile and the system profile. Their locations are listed in Table 21.3.
Was this article helpful?