Summary: Learn how a user can change the Windows PowerShell script execution policy.
How can I change the Windows PowerShell script execution policy as simply an ordinary user?
Use the –Scope parameter with the Set-ExecutionPolicy cmdlet and specify CurrentUser (the –Force parameter hides prompts from the cmdlet):
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
Summary: Microsoft Scripting Guy, Ed Wilson, continues his discussion about running scripts from a remote file share.
Microsoft Scripting Guy, Ed Wilson, is here. Some things should just be easier. For example, I should have access to client-side cmdlets to work with SharePoint. Many times, as a user, I need to accomplish repetitive tasks, and a few cmdlets could really come in handy. Running scripts from remote file shares should be easier as well.
Easier? What am I talking about? Well when someone asks a question, there are so many “it depends,” “maybe,” and “whatever” stuff going on that it really makes what should be easy very complicated. For example, in a freshly created Windows Server 2012 forest, I created a share on the domain controller. I modified the script execution policy on the client, and I could run scripts from the share just fine. No configuration, no signing, no nothing. It just worked. But to make a proclamation would take hours of testing in all different sorts of variables.
Note This is the third in a multipart series of posts. The first post was Running Scripts from a Remote File Share.The second post was Weekend Scripter: Run PowerShell Scripts from Remote File Share: Part 2. For good background info about running Windows PowerShell scripts from a remote file share, check out the guest blog post written by June Blender and Judith Herman: How to Run PowerShell Scripts from a Shared Directory.
The easy way to run a script from a remote file share is to use the Bypassmethodology. This is not a security hole, because the script execution policy and the associated settings are not really security features—they are a security convenience. This means that they are in place to remind me to do the right thing—to encourage me to follow best practices. But they are not put in place to discourage getting the job done.
So, all the discussion about the script execution policy and signed scripts can be bypassed if I need to do so. What is a common requirement? Well, running a script from a scheduled task, or from within a Group Policy Object. If the desktop and network configuration are complicated to the point of not knowing what will go on, I can use Bypassmodeand still get my scripts to run.
To illustrate this point, I change my script execution policy to Restricted. This is the way it comes out of the box. Scripts do not run.
So, if I want to run a script in Bypass mode, I can use the Run dialog box. One problem I have with the Run dialog box is that it is very small, and it does not resize. The Run box is shown here:
So, what I like to do is open Notepad, compose my command, and then paste it into the run dialog box. There are a couple of things that are important to the command. First, I add –NoExit. From a scheduled task, I would not do this. I would, instead, have my script output to a log file. I added –NoExit so that I could see the output. The key to making this work is specifying the –ExecutionPolicy parameter of Bypass. I then provide the UNC path to the script that I want to run. I would use this exact sort of syntax (without the NoExit) to run a script from a scheduled task. Here is my command:
powershell -noexit -executionpolicy bypass -file \\dc1\Share\ServerNameBios.ps1
Here is the command in Notepad:
When the command runs, it opens a new instance of Windows PowerShell, executes the script, and displays the output from the script. The execution policy of the newly created instance of Windows PowerShell is Bypass. This is shown in the following image.
Well, that is it for today. I am heading outside, so have a great day, and join me tomorrow as I begin Active Directory Domain Services Migration Week.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell 3.0 in Windows 8 to view network adapter binding information.
How can I use Windows PowerShell 3.0 in Windows 8 to review network adapter binding information?
Use the Get-NetAdapterBinding function and pipe the resulting information to the Format-List cmdlet:
Get-NetAdapterBinding | Format-List *
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to add office locations in Active Directory Domain Services.
Hey, Scripting Guy! We are in the midst of a domain migration at work, and I need to clean up a number of attributes in Active Directory prior to our migration. Part of our issue is that we have attributes that are missing values, and I just hate to migrate empty stuff. Is there anything you can do to help?
—TV
Hello TV,
Microsoft Scripting Guy, Ed Wilson, is here. I am listening to my customized Internet radio station with a cool app I found for Windows 8 in the Windows Store. It is really cool to be able to select my listening preferences. I have actually spent a bit of time and created a couple of special Scripting Guy stations. It all depends on what I am writing. For example, Active Directory Domain Services questions simply beg for a bit of classic New Orleans style jazz—or, that is just me. Jazz also goes well with spearmint, wintergreen, peppermint, and lemon grass with a spoon full of Gun Powder Green tea. So I have my tunes and my tea. I guess I will answer your question.
The first thing I need to do is to find the attribute that is missing. I first look at the user in Active Directory Users and Computers. This is shown here:
It seems that the Office attribute is missing from all of the user objects. I add a bunch of AAAAAs to the Office field so I can find the attribute in ADSI Edit. I check with ADSI Edit, and sure enough the Office attribute is named physicalDeliveryOfficeName as shown in the following image. Good, that makes it easy.
I look around, and all of the cities are populated. So I check ADSI Edit, and I figure out that it uses a lower-case l—as in L for Location. This is shown here.
In my example, the office names are the same as the city names. So all I need to do is to read all of the city names from all users in the TestOU organizational unit and add the city value to the Office attribute. First, let me make sure I can get the cities for all users. This is shown here:
Get-ADUser -Filter * -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties l
The command and its output are shown in the image that follows.
As it turns out, I do not need to know the physicalDeliveryOfficeName attribute name because Set-ADUser has an –Office parameter. I compose the following command and use the –Whatif parameter to ensure that things will do what I want them to do.
PS C:\> Get-ADUser -Filter * -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties l
| Foreach {Set-ADUser $_ -Office $_.l -whatif}
The command and the output are shown here.
So, I remove the –Whatif and run the command again. This time, nothing returns from the command. (On my system, it takes about five seconds to run.) Here is the command (this is a one-line command broken at the pipe for readability):
Get-ADUser -Filter * -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties l|
Foreach {Set-ADUser $_ -Office $_.l}
I use Active Directory Users and Computers and check a few users. Here is the first user. The command worked.
TV, that is all there is to using Windows PowerShell to add office locations to users in a specific AD DS OU. Active Directory Domain Services Week will continue tomorrow when I will talk about Active Directrory migration cleanup.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell 3.0 in Windows 8 to see network adapters that are bound to TCP/IP.
How can I find all network adapters that are bound to TCP/IPv4 by using Windows PowerShell 3.0 in Windows 8?
Use the Get-NetAdapterBinding function, pipe the results to a Where-Object cmdlet, and filter for the BindName equal to ‘tcpip’:
Get-NetAdapterBinding | where bindname -eq 'tcpip'
Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to add user principal names to users in Active Directory.
Hey, Scripting Guy! We are planning for our Active Directory migration, and as part of that, I am reviewing users. The problem is that I found out that whoever set up our original installation did not assign values for user principal names (UPN). This will cause us a problem as we move to a federated environment. Can you offer an easy way to populate this value?
—CG
Hello CG,
Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sitting on our lanai and checking my scripter@microsoft.com email on my Microsoft Surface RT. I received an email from one of my friends in Hawaii. He was telling me about a Hukilau he went to over the weekend. From his description, it makes me want to grab the Scripting Wife and head out west on the next available flight. The big problem right now, is the weather. I prefer August in Australia to August in Hawaii—it is really hot there.
In Active Directory Users and Computers, the UPN shows up as the user logon name. It displays the UPN in two different fields, as shown in the following image.
To find the actual Active Directory attribute name, I add a bunch of AAAs to the user logon name, and select a domain from the drop-down list. I then go into ADSI edit and look up the value. I see the following:
I use the Get-ADUser cmdlet to look for existing values for the UserPrincipalName attribute. To find the value of the UserPrincipalName attribute, I have to specify it for the –Properties parameter. I specify the SearchBase of the organizational unit (OU), and I use the * filter. This is shown here:
Get-ADUser -Filter * -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties userPrincipalName
The command and associated output are represented in the following image.
I use the Get-ADUser cmdlet to retrieve all the users to set. I pipe the resulting user objects to the Foreach-Object cmdlet, and in the script block, I use the Set-ADUser cmdlet. The Set-ADUser cmdlet has a –userPrincipalName parameter that makes it easy to set the UPN.
To create the UPN, I use a hardcoded domain name, and I get the user’s name from the Name attribute. I use parameter substitution and the –f format specifier to concatenate the user principal name. The command is shown here (this is a single-line command that I broke at the pipe for readability):
Get-ADUser -Filter * -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName ("{0}.{1}" -f $_.name,"iammred.net")}
CG, that is all there is to using Windows PowerShell to add the UPN for user accounts. Active Directory Week will continue tomorrow when I will talk about more cool Windows PowerShell stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Learn how to use Windows PowerShell to get the DHCP Server database information.
How can I use Windows PowerShell to get the database information for a DHCP server if I do not know the name of the server?
Use the ServerName property from the object returned by Get-DHCPServer to get the computer name, then use the Get-DhcpServerDatabase:
Get-DhcpServerDatabase -ComputerName (Get-DhcpServer).ServerName
Note The DHCP functions come from the DHCPServer module obtained via the RSAT tools for Windows Server 2012.
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to modify the sign-in script and profile path in Active Directory.
Hey, Scripting Guy! We are in the middle of an Active Directory migration (primarily moving our client computers from Windows XP to Windows 8). We are also consolidating our file servers and our profile servers. We have multiple sites, and in the past, each site had a one or more domain controllers, multiple file and print servers, and other stuff as needed.
Now, we are collapsing that infrastructure into a single server running Hyper-V. Needless to say, our profiles will be moving to different servers, and we will also be changing our sign-in scripts. So I need an easy way to modify these settings for our users. The new servers will be based on the user’s city locations. Can you help?
—RA
Hello RA,
Microsoft Scripting Guy, Ed Wilson, is here. Things have been busy around the Scripting House. I got up early to check the scripter@microsoft.com email and to write a couple of proposals for Windows PowerShell Saturday in Atlanta. According to Mark, I will be making two presentations—one for the beginner track and one for the advanced track. In addition, I have been working on my presentation that I will be conducting remotely for Windows PowerShell Saturday in Singapore.
The first thing we need to do is to find the ADSI attribute names for the profile path and for the sign-in script. I open up one of the user profiles and type some bogus information so that I can find the attributes in ADSI Edit. Here is the page from Active Directory Users and Computers:
Now I navigate to the same user object in ADSI Edit and look up the ADSI property names. The names make sense: ProfilePath and ScriptPath. This is shown here:
Now I need to retrieve the information from Active Directory Domain Services (AD DS). I could do all this from inside the Windows PowerShell console, but I decided to use the Windows PowerShell ISE instead. It has better intellisense, and for something like this, it makes things a bit more readable. I decide to use a couple of variables to hold the organizational unit (OU) and the properties that I need to retrieve. I then use Get-ADUser to retrieve the information. Here is this portion of the script:
Import-Module ActiveDirectory
$ou = "OU=Testou,Dc=Iammred,Dc=Net"
$properties = "ProfilePath","ScriptPath", "l"
Get-ADUser -Filter * -SearchBase $ou -Properties $properties
I can highlight only this section of the script to test it. After I see that it works, I pipe the returned information to the Foreach-Object cmdlet. The hardest part of the script is to create the profile path and the script path. I decide to use parameter substitution and the Format operator to do this because, for me anyway, it is easier to read.
I build the profile path based on the city name. I then add Storage1 (which is the name of the storage server) and Profiles (which is the name of the folder that holds the profiles). Next, I use the user’s SamAccountName attribute. Here is the string:
$ProfilePath = "{0}\storage1\profiles\{1}" -f $_.l, $_.SamAccountName
Now, to createthe script path. To do that, I again use the city name. I also store the scripts in Storage1, and I place them in a folder named Scripts. The sign-in script is based on the city name and the word LogonScript. Therefore, I am only substituting a single word: the city name, which is the l attribute. Here is the string I use for this:
$ScriptPath = "{0}\storage1\scripts\{0}_logonScript.ps1" -f $_.l
The rest is really easy. All I need to do is to use the Set-ADUser cmdlet to plug in the values. Here is that command:
Set-ADUser $_.samaccountname -ProfilePath $ProfilePath -ScriptPath $ScriptPath
The complete script is shown here:
Import-Module ActiveDirectory
$ou = "OU=Testou,Dc=Iammred,Dc=Net"
$properties = "ProfilePath","ScriptPath", "l"
Get-ADUser -Filter * -SearchBase $ou -Properties $properties |
ForEach-Object {
$ProfilePath = "{0}\storage1\profiles\{1}" -f $_.l, $_.SamAccountName
$ScriptPath = "{0}\storage1\scripts\{0}_logonScript.ps1" -f $_.l
Set-ADUser $_.samaccountname -ProfilePath $ProfilePath -ScriptPath $ScriptPath
}
When I run the script, nothing returns. But that is what I want (I really do not want a whole bunch of errors). Here is the ISE and the blank output from running the script:
I check Active Directory Users and computers to ensure that everything worked as planned. It is fine, as shown here:
RA, that is all there is to using Windows PowerShell to create values for the sign-in script and the profile path. Active Directory Week will continue tomorrow when I will talk about logging an attribute change.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell to display replication connections in Active Directory Domain Services.
How can I use a cmdlet from the Active Directory module to display replication connections in AD DS?
Use the Get-ADReplicationConnection cmdlet and select the ReplicateFromDirectoryServer property and the ReplicateToDirectoryServer property (this is a single-line command broken at the pipe character for readability):
Get-ADReplicationConnection |
select ReplicateFromDirectoryServer, ReplicateToDirectoryServer
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to log changes made to Active Directory Domain Services attribute values.
Hey, Scripting Guy! We are in the process of merging a couple of resource domains, and we need to modify some user accounts prior to the move. I have been tasked with making the changes, and I plan to use Windows PowerShell to perform the actual work. I need to create before and after logs. The before log shows the value of the attributes that I am going to change prior to running the script, and the after log will show the value of the attributes after running the script. Can you show me how I might go about doing this? Thanks, Scripting Guy, you are the best!
—CX
Hello CX,
Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sitting on the lanai, and sipping a cup of English Breakfast tea. I put a bit of lemon grass, hibiscus flower, rose hips, spearmint, and a cinnamon stick in the tea. The flowers give it a citrus flavor, and the mint makes it very refreshing. The trick is that I only let it steep for three minutes, and that keeps it from becoming too bitter. It took me several tries to get this one just right. Because it is pretty early, it is not too hot or humid outside yet. I have my Surface RT, and am checking my scripter@microsoft.com email.
So, CX, you did not specify how you want your logging to take place, but I decided that exporting to a CSV file would work out well. Then you could import it into Microsoft Excel if you want to do so.
The first thing to do is to create a little script that will populate an attribute with before values. I am going to populate the Post Office Box attribute, so I need to look it up in ADSI edit. I come up with the following (surprisingly, it is named postOfficeBox):
I write a little script to add values to this attribute. Here is the script:
Import-Module activeDirectory
$ou = "ou=testou,dc=iammred,dc=net"
$i = 1
Get-ADUser -Filter * -SearchBase $ou |
ForEach-Object {
Set-ADUser $_ -POBox "Post Office Box $i"
$i++ }
Now I want to see how many different cities are represented by the users in the organizational unit (OU). I modify my script a bit and use the –Unique parameter from the Select-Object command. This is shown here:
Get-ADUser -Filter * -SearchBase $ou -properties $properties | select l -Unique
The following output tells me that I have three cities:
Atlanta
Charlotte
Jacksonville
Therefore, I need to add a bit of logic to detect the city. If the city is Atlanta, I will set the postOfficeBox attribute to 222; if it is Charlotte, I will set it to 333; and if it is Jacksonville, I will set it to 444.
The first thing I do is use the Get-ADUser cmdlet to return the user name and the postOfficeBox attribute. I use the Select-Object cmdlet to get these two attributes, and I pipe the output to Export-CSV. No problem…until I open the spreadsheet in Excel. Here is the results:
The issue is that for some reason, the postOfficeBox attribute is a collection. I therefore modify my script a bit, and I select the first PO Box. Here is the script:
Import-Module activeDirectory
$ou = "ou=testou,dc=iammred,dc=net"
$Before = "c:\fso\before.csv"
$properties = "PostOfficeBox"
Get-ADUser -Filter * -SearchBase $ou -properties $properties |
Select name, @{L='pobox';E={$_.postofficebox[0]}} |
Export-Csv -Path $before -NoTypeInformation -Force
Now I open the script in Excel, and it appears like I expected:
So now I use the Get-ADUser cmdlet to retrieve my user objects. I pipe everything to a Foreach-Object cmdlet, and I use a Switch statement inside the Foreach-Object. I read a Switch statement like a series of If statements, for example: If the city matches Atlanta, then I set the POBox variable to 222.
I then use the Set-ADUser cmdlet inside the Foreach-Object cmdlet to make the actual changes. Here is the script:
Import-Module activeDirectory
$ou = "ou=testou,dc=iammred,dc=net"
$properties = "l","PostOfficeBox"
Get-ADUser -Filter * -SearchBase $ou -properties $properties |
ForEach-Object {
Switch ($_.l)
{ "Atlanta" {$pobox = "POBox 222"}
"Charlotte" {$pobox = "POBox 333"}
"Jacksonville" {$pobox = "POBox 444"} }
Set-ADUser $_ -POBox $pobox
}
Now I run my documentation script again and open the Excel spreadsheet. I can see that the changes took place as expected. Cool.
CX, that is all there is to using Windows PowerShell to make changes to AD DS attribute values and to log the changes. Active Directory Week will continue tomorrow when I will talk about different ways of working with Active Directory.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell to show the group of approved Windows PowerShell verbs.
How can I find the grouping information for a couple of approved verbs that I want to use to name my advanced functions?
Use the Get-Verb function, and supply an array of verbs to the function:
get-verb ping, receive
Summary: Guest blogger, Rolf Masuch, talks about using Windows PowerShell to customize Server Manager.
Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest post written by Rolf Masuch, who is a senior consultant for Microsoft in Germany. Today is Rolf’s birthday, and he wanted to start the celebration off right by sharing a couple of cool scripts with us. Take it away Rolf…
When it comes to the new versions of Windows Server 2012 R2 and Windows Server 2012, one of my most-loved changes is to Server Manager. The new Server Manager Dashboard looks like this:
Lots of documents have been written already about this new way of working. Today I’d like to share two extension scripts that I thought would be helpful for the community because when it comes to automating Server Manager, you cannot do two things:
You will find the respective menu entries in Server Manager when you click Manage.
But first, let’s look behind the curtain of Server Manager. It stores information in an XML file that is saved per user at this location:
$ENV:APPDATA\Microsoft\Windows\ServerManager\ServerList.xml
Additionally, it is useful to know that every time you close a running Server Manager instance, it can overwrite your scripted changes. We want to take care that before we make changes to the XML file, we close the Server Manager process. We also need to make all changes in an elevated process.
When it comes down to writing additional entries to the file, you may think, “Hey, it is just XML, this is easy.” But when you look at the structure of the XML file, you see that this is not so simple. The following example is from a freshly installed system with one additional group:
ServerManager.xml
***
<?xml version="1.0" encoding="utf-8"?>
<ServerList xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" localhostName="MyCloudComp001" xmlns="urn:serverpool-schema">
<ServerInfo name="MyCloudComp001" status="1" lastUpdateTime="2013-08-08T09:01:26.7659233+00:00" locale="en-US" /><ServerGroupInfo id="3" name="MyGroup" />
<ServerGroupMembership server="MyCloudComp001" serverGroupId="3" />
</ServerList>
***
As you see from the initial lines, the XML structure is using an additional namespace that is named urn:serverpool-schema. When you want to add new elements to this structure, you need to take care of that. So how is it done?
Let’s look at the script Add-ServerToManagedServerList.ps1. Here are the essential lines:
$NewServer = $ServerList.CreateElement("ServerInfo")
$NewServer.SetAttribute("name",$ComputerName.ToString()) | Out-Null
$NewServer.SetAttribute("xmlns","urn:serverpool-schema") | Out-Null
$ServerList.ServerList.AppendChild($NewServer) | Out-Null
So setting the right attribute in the right notation does the trick for us. Now I have the newly added server in Server Manager.
The same is true when it comes to adding the server to an existing group.
$NewServerInGroup = $ServerList.CreateElement("ServerGroupMembership")
$NewServerInGroup.SetAttribute("server",$ComputerName.ToString()) | Out-Null
$NewServerInGroup.SetAttribute("serverGroupId",$PSItem.Id) | Out-Null
$NewServerInGroup.SetAttribute("xmlns","urn:serverpool-schema") | Out-Null
$ServerList.ServerList.AppendChild($NewServerInGroup) | Out-Null
Because this is an existing group, we have to make sure that the group’s ID is added to the attributes of the entry. So this is how you add a new server to your list of managed servers. Simple, isn’t it? A new server group is shown here:
You may also want to add some custom groups. The added script, New-ServerManagerGroup.ps1, helps you take care of that. It creates a random number and uses it as the needed group ID.
$Global:ServerGroupID = Get-Random -Maximum 1000
$NewServerGroup = $ServerList.CreateElement("ServerGroupInfo")
$NewServerGroup.SetAttribute("id",$Global:ServerGroupID) | Out-Null
$NewServerGroup.SetAttribute("name",$Name) | Out-Null
$NewServerGroup.SetAttribute("xmlns","urn:serverpool-schema") | Out-Null
$ServerList.ServerList.AppendChild($NewServerGroup) | Out-Null
I’ve added additional switches, such as –Backup (to save the previous ServerManager.xml) and –StartServerManager (for launching Server Manager after your additions). Be aware that the provided scripts always check for a servermanager.exe process and end this process silently for you.
I hope these little scripts help the community, and I’m looking forward to your comments.
The following scripts are uploaded on the Script Center Repository:
~Rolf
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell to find case-specific strings.
How can I find a particular, case-sensitive word in a string?
Use Select-String and specify the –CaseSensitive switch:
"Hey Scripting Guy","hey scripting guy" | Select-String -Pattern 'hey' -CaseSensitive
Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding Windows PowerShell in Windows 7.
Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sipping a cup of English Breakfast tea, with goji berries, lemon grass, and cinnamon. The taste is quite nice, and because the goji berries are sweet, I do not need to add any sugar or honey to my tea. Goji berries are not indigenous to Charlotte, North Carolina, so I use dried berries that I order with my other herbs and spices. Along with my tea, I am eating some homemade scones that the Scripting Wife made with the goji berries. They are rather lovely.
One of the more common questions I get about Windows PowerShell 3.0 runs something like this,“I have Windows PowerShell 3.0, but I do not see the Get-Disk cmdlet.” (Or words to that effect.) Part of the confusion stems from confusing Windows PowerShell 3.0 with the operating system.
Note For information about installation, refer to Install PowerShell 3.0 on Windows 7.
For example, in Windows 7, when I install Windows PowerShell 3.0, I have access to 355 cmdlets and functions. To find this information, I first imported all of the modules, and then I used the Get-Command cmdlet to retrieve all functions and cmdlets. This is shown here:
In Windows 8, I do not need to install Windows PowerShell 3.0 because it is part of the operating system. When I import all of the modules and count the number of cmdlets and functions in Windows 8, I come up with 988. The output is shown in the following image.
Note Interestingly enough, the output from $PSVersionTable is a little different in Windows 7 and Windows 8.
So, where does the difference between Windows PowerShell 3.0 in Windows 7 and In Windows 8 come from? Well, it comes from the modules. In Windows 8, many of the teams at Microsoft created modules to permit remote management of aspects of their configuration. In many cases, this took the form of wrapping various WMI classes that have been part of the operating system for a long time. Therefore, just because I am working in Windows 7, it does not mean that I am unable to use Windows PowerShell to manage it—but it will be a bit more difficult.
So what are the modules that are available in Windows 7 after I install Windows PowerShell 3.0? They are listed here:
PS C:\> Get-Module -list | select name
Name
----
AppLocker
BitsTransfer
CimCmdlets
ISE
Microsoft.PowerShell.Diagnostics
Microsoft.PowerShell.Host
Microsoft.PowerShell.Management
Microsoft.PowerShell.Security
Microsoft.PowerShell.Utility
Microsoft.WSMan.Management
PSDiagnostics
PSScheduledJob
PSWorkflow
PSWorkflowUtility
TroubleshootingPack
To get an idea of the number of cmdlets in each module, I decide to create a custom property in the Select-Object cmdlet. Here is the command that I created (this is a single-line command that I broke into multiple lines for easier reading):
Get-Module -list | select name,
@{L='commands';E={(Get-command -commandtype Function, Cmdlet -module $_.name).count}} |
sort commands -Descending| ft –auto
The command and its associated output are shown in the following image:
By examining the modules and the cmdlets, I can see where the Windows PowerShell 3.0 cmdlets and functions reside, and determine from whence they actually come.
Join me tomorrow when I will examine Windows PowerShell 3.0 in Windows 8.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Use Windows PowerShell to write your BitLocker recovery key to a text file.
If I forgot to save my BitLocker recovery key when I enabled BitLocker on my laptop, how can I use Windows PowerShell to write it to a text file so I can copy it to a USB key for safe keeping?
From an elevated Windows PowerShell console, use the Get-BitLockerVolume function, select -MountPoint C, choose the KeyProtector and the RecoveryPassword properties, and then redirect the output to a text file:
(Get-BitLockerVolume -MountPoint C).KeyProtector.recoverypassword > c:\bitlockerkey.txt
Summary: Microsoft Scripting Guy, Ed Wilson, talks about understanding Windows PowerShell 3.0 in Windows 8.
Microsoft Scripting Guy, Ed Wilson, is here. It is an exciting and great day! I have been working a bit to solidify the editorial calendar for the Hey, Scripting Guy! Blog. I can say that there are some absolutely awesome posts coming up in the next couple months. I am not just saying this because I am writing them. Nope. I have a great lineup of guest writers. The upcoming stuff will simply rock!
One of the really great things about Windows 8 is the implementation of Windows PowerShell 3.0. But many of the really cool commands (cmdlets or functions) are not strictly Windows PowerShell 3.0. For example, one function I use on a regular basis when I am traveling is Get-NetAdapter. This command tells me if a network adapter is up. Because I toggle my wireless and my Ethernet adapter connections (on or off depending on the network), I often need to see if a particular adapter is up.
Another function I use a lot when I am traveling is the Get-NetConnectionProfile function. This tells me how a particular network adapter has been identified by the operating system. I can modify the profile by using Set-NetConnectionProfile. I need to use this a lot when I am traveling and I want to demonstrate Windows PowerShell.
Neither of the two previously mentioned functions are part of Windows PowerShell 3.0, per se. They are included in modules that ship with Windows 8. The associated modules are shown here:
PS C:\> Get-Command Get-NetConnectionProfile, Get-NetAdapter
CommandType Name ModuleName
----------- ---- ----------
Function Get-NetConnectionProfile NetConnection
Function Get-NetAdapter NetAdapter
Am I being pedantic? If so, it is not my intention. It is important to know where specific functionality arises, so that when I install Windows PowerShell 3.0 onto a computer running Windows 7, I will know what to expect. This concept will be important when Windows 8.1 ships with Windows PowerShell 4.0 because Windows PowerShell 4.0 in Windows 8.1 will expose certain cmdlets and functions that may not be available if I install Windows PowerShell 4.0 on a down-level system.
With all the great commands in Windows 8, it is easy to forget that the capability comes from modules that ship with the operating system, and that they are not part of Windows PowerShell 3.0 core installation. But it is Windows PowerShell 3.0 that makes these cool modules shine. Most of the capability comes from the CIM infrastructure that is part of the Windows Management Framework 3.0 (where you obtain Windows PowerShell 3.0).
For example, the Get-NetAdapter function uses CIM to expose network adapter information. It is very convenient. The command and its associated output are shown here:
I can achieve the same output in Windows 7 by using Windows PowerShell 3.0. I use the Get-CimInstance cmdlet, query the Win32_NetworkAdapter WMI class, and choose the appropriate properties. The command is a bit longer than just typing Get-NetAdapter, but if I use it all the time, all I need to do is write my own function. Following is the command (gcim is the alias for Get-CimInstance, Select is the alias for Select-Object, and ft is the alias for Format-Table). This command is a single-line command that I broke at the pipe character for readability.
gcim win32_networkadapter |
select netconnectionid, description, interfaceindex, macaddress, speed |
ft * -auto
Here is the command and the output from the command:
Join me tomorrow as I begin a series of posts called Windows PowerShell Workflow for Mere Mortals. It is a great series, and you will not want to miss it.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Learn how to display all Windows PowerShell modules and cmdlet names.
How can I get output that shows Windows PowerShell module names and the cmdlets or functions that are contained inside the modules?
Use the Get-Module cmdlet, and then for each module, display the name and use Get-Command (gcm is an alias) to retrieve the cmdlets and functions (this is a single-line command broken at the pipe character for readability):
Get-Module -ListAvailable |
foreach {"`r`nmodule name: $_"; "`r`n";gcm -Module $_.name -CommandType cmdlet, function | select name}
Summary: Microsoft Scripting Guy, Ed Wilson, begins a five-part series about Windows PowerShell Workflow.
Hey, Scripting Guy! What is up with Windows PowerShell Workflow? Everyone acts like it is some deep, dark mystery—similar to trying to understand neutrinos. So come on…it is Windows PowerShell, so how hard can it be?
—MD
Hello MD,
Microsoft Scripting Guy, Ed Wilson, is here. This week I am going to address some questions and comments that have been collecting about Windows PowerShell Workflow. I like using Windows PowerShell Workflow because it offers a number of significant capabilities that help solve rather interesting issues.
Note This is the first in a five-part series of blog posts about Windows PowerShell Workflow for “mere mortals.” For more information, see these Hey, Scripting Guy! posts about Windows PowerShell Workflow. For a conceptual introduction, see When Windows PowerShell Met Workflow.
Windows PowerShell Workflows are cool because the commands consist of a sequence of related activities. I can use a workflow to run commands that take an extended period of time. By using a workflow, my commands can survive reboots, disconnected sessions. They can even be suspended and resumed without losing the data. This is because the workflow automatically saves state and data at the beginning and at the end of the workflow. In addition, it can use specific points that I specify. These persistence points are like checkpoints or snapshots of the activity. If a failure occurs that is unrecoverable, I can use the persisted data points, and then resume from the last data point instead of having to begin the entire process anew.
Note Windows PowerShell Workflow is Windows Workflow Foundation. But instead of having to write the workflow in XAML, I can write the workflow by using Windows PowerShell syntax. I can also package the workflow in a Windows PowerShell module. For detailed documentation, see Windows Workflow Foundation.
The two main reasons to use Windows PowerShell Workflow are reliability and performance when performing large scale or long-running commands. These reasons break down into the following key points:
I can run a workflow that uses Windows PowerShell cmdlets if the target (the managed node) runs at least Windows PowerShell 2.0. I do not need Windows PowerShell 2.0 if the workflow does not run Windows PowerShell cmdlets. I can use WMI or CIM commands on computers that do not have Windows PowerShell installed. This means that I can use Windows PowerShell workflow in a heterogeneous environment.
The computer that runs the workflow is the host (client) computer. It must be running at least Windows PowerShell 3.0 and have Windows PowerShell remoting enabled. In addition, the target (managed node) computer must have at least Windows PowerShell 2.0 with Windows PowerShell remoting enabled if the workflow includes Windows PowerShell cmdlets.
Although much of the focus with Windows PowerShell Workflow is about large network management, I can use Windows PowerShell Workflow on my own local computer. I might want to do this if the task at hand might take a long time to run. Therefore, from a learning standpoint, it makes sense to begin with a workflow that simply works on my local computer.
To write a workflow, I begin with the Workflowkeyword. I provide a name for the workflow, and inside the braces (script block), I specify the script that I want to use. The syntax is very much like a Windows PowerShell function. Here is my basic workflow:
Workflow HelloUser
{ "Hello $env:USERNAME" }
Just like a Windows PowerShell function, I need to run the script and load the workflow prior to using it. In the Windows PowerShell ISE, I run the script that contains the workflow, and then I can use the workflow in the immediate window. This is shown in the following image:
I can use normal Windows PowerShell commands and add logic to my workflow. The following workflow uses the Get-Date cmdlet to retrieve the time in 24-hour format. Then if the hour is less than 12, it displays “good morning.” If the hour is between 12 and 18, it displays “good afternoon.” Otherwise, it displays “good evening.” Here is the workflow:
Workflow HelloUserTime
{
$dateHour = Get-date -UFormat '%H'
if($dateHour -le 12) {"good morning"}
ELSeIF ($dateHour -gt 12 -AND $dateHour -le 18) {"good afternoon"}
ELSE {"good evening"}
}
MD, there is a start for using Windows PowerShell Workflow. Windows PowerShell Workflow for Mere Mortals Week will continue tomorrow.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Summary: Learn how to use Windows PowerShell to display the date in locale-specific format.
How can I use Windows PowerShell to display the day, month, and two-digit year in locale specific format?
Use the Get-Date cmdlet and the –uformat parameter:
get-date -UFormat %x
Summary: Microsoft Scripting Guy, Ed Wilson, continues a five-part series about Windows PowerShell Workflow.
Hey, Scripting Guy! So Windows PowerShell Workflow seems pretty cool. But I am wondering if it is possible to use it to easily provide workflow types of things for remote computers? Is this possible?
—BB
Hello BB,
Microsoft Scripting Guy, Ed Wilson, is here. We are enjoying a cool stretch of weather here in Charlotte, North Carolina. In fact, we have the windows open. We are also enjoying our visiting friends from Hamburg, Germany. So not only do we have great weather, but we have great company.
Note This is the second in a five-part series of blog posts about Windows PowerShell Workflow for “mere mortals.” You should read PowerShell Workflow for Mere Mortals: Part 1 before you read this post. For more information about workflow, see these Hey, Scripting Guy! Blog posts: Windows PowerShell Workflow.
One of the reasons for using a Windows PowerShell Workflow is to be able to easily execute commands in parallel. This can result in some significant time savings.
Note For an example of the time savings that are possible by using a Windows PowerShell Workflow and running commands in parallel, see the excellent post written by Windows PowerShell MVP, Niklas Goude, Use PowerShell Workflow to Ping Computers in Parallel.
To perform a parallel activity by using Windows PowerShell Workflow, use the Foreach keyword with the –Parallel parameter. This is followed by the operation and the associated script block. The following script illustrates this technique:
Foreach -Parallel ($cn in $computers)
{ Get-CimInstance -PSComputerName $cn -ClassName win32_computersystem }
One of the things to keep in mind (as a major source of early frustration) is that when I call the Get-CimInstance cmdlet from within the script block of my parallel Foreach keyword, I have to use the automatically added PSComputerName parameter, not the ComputerName parameter I would normally use with the cmdlet. This is because this is the way that Windows PowerShell Workflow handles computer names. If I look at the command-line syntax for Get-CimInstance, I do not see the ––PSComputerName parameter at all.
The nice thing is that if I forget to use –PSComputerName, and I try to run the Windows PowerShell Workflow, an error message appears. The message is detailed enough that it actually tells me the issue and tells me what I need to do to solve it.
When I rename the parameter in Get-CimInstance, I can run the workflow, and it does not generate any errors. This is shown here.
The complete GetComputerInfo workflow is shown here:
Workflow GetComputerInfo
{
$computers = "server1","client1"
Foreach -Parallel ($cn in $computers)
{ Get-CimInstance -PSComputerName $cn -ClassName win32_computersystem } }
I call the workflow, and I am greeted with computer information for each of the servers with names I stored in the $computers variable. The script and the output from the script are shown here.
BB, that is all there is to use Windows PowerShell Workflow on a remote computer. Windows PowerShell Workflow Week will continue tomorrow when I will talk about more cool workflow stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy