Meet the third PowerShell (part I)
The pace of development of modern technologies is such that we can hardly keep up with them. But today we’ll run a little bit ahead, learn about the innovations of PowerShell v3, and look at them not only with our eyes, but also with our hands.
I built two Windows Server 2012 RC based machines for Hyper-V, created a forest from one domain called
Also, I should mention that not all the terms I use are already localized and are on the Microsoft language portal , so I give their translation exactly as I understand these terms, and in brackets I give the original name in English.
First, let's just list them:
After its launch, without parameters, a window appears, from which blows grandeur and chic:
If you had to search for a particular cmdlet on TechNet, or even use .NET objects, then here you are, I don’t want all the modules, all the cmdlets.
')
Here, if you please, manage the DNS server and DNS client service cmdlets, and if you select any module, for example, a network, you can find out the routing table configuration cmdlets or, say, TCP / IP parameters of network interfaces.
I also tried to look for the words "share", "user", "acl", "policy", "adapter", and so on and so forth, try, this is interesting.
Associated with the previous, but not directly dependent. In PowerShell v2 in Windows Server 2008 R2, in order to perform certain operations, you need to connect this or that module, PowerShell v3 automatically determines which module is responsible for launching the cmdlet and loads this module in the background, without any questions.
Let's compare. I decided to get a list of group domain policies, if I try to load them into PowerShell v2:
Then we get an error, because the GroupPolicy module is not loaded:
Now, if you repeat, everything goes fine:
In PowerShell v3, everything is fine initially:
Here, it seemed to me, the developers decided to bring the language closer to SQL, well, at least some analogy can be traced. The point is that they introduced new syntaxes for the
instead
In my opinion, it is doubtful.
Another thing is
instead
already nothing, without any braces curly with dollar quotes.
Also, a couple of new operators appeared:
The most remarkable innovation that I want to talk about in the first part is the configuration of the session in conjunction with the delegation of administrative powers. The actual configuration file is a file with the .pssc extension, which only contains a hash table of properties and values: authorship, language, variables, function definitions, and so on. There are other properties in the session configuration itself:
A picture similar to this one will appear:
See how many customizable parameters? You can even compare with the picture that appears when you run this command in PowerShell v2 and feel the difference.
But how to use it? And now I will show, I confess, I was picking long enough to write these few lines. So, we consistently execute:
Notice, I limited the configuration to the
Convenient thing, right? By limiting the modules and cmdlets inside PowerShell, we can easily and naturally, within our team of administrators, make some employees responsible for the DNS, others for the network, and users, for example, to give the right to make snapshots of their Hyper-V machines inside VDI, and no one know the credentials of the user from which the task is performed! And the ready configuration file is simply transferred from one place to all other servers with similar functions.
In the next part we will go further, or rather up the list, analyze the reliable sessions, scheduled tasks and, of course, workflows. Well, and, perhaps, a little touch on the new PowerShell ISE, there is also something to look at.
Stand
I built two Windows Server 2012 RC based machines for Hyper-V, created a forest from one domain called
litware.inc . The two machines in the domain are called w2012dc1.litware.inc and w2012cl1.litware.inc , respectively. At w2012dc1 domain services and DNS w2012cl1 , and at w2012cl1 nothing revolves except, in fact, the OS itself. Also in the domain there is a user user1 , a member of the domain users group. You could, of course, install Windows 8 RC on a second machine for beauty, so to speak, but I decided to save a little bit of disk space by taking one parent virtual hard disk and hooking two children to it instead of using two independent virtual hard disks.
Also, I should mention that not all the terms I use are already localized and are on the Microsoft language portal , so I give their translation exactly as I understand these terms, and in brackets I give the original name in English.
New opportunities
First, let's just list them:
- Workflows (Eng. Workflows ) - these are some processes running sequentially or in parallel, performing complex management tasks. Actually, PowerShell v3 now includes support for Windows Workflow Foundation, and the PowerShell workflows themselves are repeatable, parallelizable, interruptible, and recoverable.
- Robust sessions ( Robust sessions ) are PowerShell sessions that are automatically restored after network turmoil and similar interruptions. Also, this technology allows you to disconnect from a session on one machine and connect to the same session on another.
- Scheduled jobs (Eng. Scheduled jobs ) - PowerShell jobs that can be executed at a certain interval, or in response to an event.
- Special session configuration ( Custom session configurations ) - For each PowerShell session, you can predetermine a specific set of parameters and save them in a special configuration file, then to enter the session on a ready-made one.
- Simplified language syntax (as stated), the simplified syntax allows the PowerShell script to look less like a program and more like a natural human language.
- Search cmdlets (eng. Cmdlet discovery ) - automatic loading of the module in which the cmdlet is located, if this module is, of course, installed on the machine.
- Show-Command is just one of the new cmdlets, with which we, perhaps, will begin.
Show-command
After its launch, without parameters, a window appears, from which blows grandeur and chic:
If you had to search for a particular cmdlet on TechNet, or even use .NET objects, then here you are, I don’t want all the modules, all the cmdlets.
')
Here, if you please, manage the DNS server and DNS client service cmdlets, and if you select any module, for example, a network, you can find out the routing table configuration cmdlets or, say, TCP / IP parameters of network interfaces.
I also tried to look for the words "share", "user", "acl", "policy", "adapter", and so on and so forth, try, this is interesting.
Cmdlet discovery
Associated with the previous, but not directly dependent. In PowerShell v2 in Windows Server 2008 R2, in order to perform certain operations, you need to connect this or that module, PowerShell v3 automatically determines which module is responsible for launching the cmdlet and loads this module in the background, without any questions.
Let's compare. I decided to get a list of group domain policies, if I try to load them into PowerShell v2:
Get-GPO -All | ft Id # Id ,
Then we get an error, because the GroupPolicy module is not loaded:
Import-Module GroupPolicy
Now, if you repeat, everything goes fine:
In PowerShell v3, everything is fine initially:
Simplified language syntax
Here, it seemed to me, the developers decided to bring the language closer to SQL, well, at least some analogy can be traced. The point is that they introduced new syntaxes for the
Foreach-Object and Where-Object cmdlets. Although the practical value of Foreach :
Get-Service | Foreach Name
instead
Get-Service | Foreach {$_.Name}
In my opinion, it is doubtful.
Another thing is
Where :
Get-Service | Where Status -eq Running
instead
Get-Service | Where {$_.Status -eq "Running"}
already nothing, without any braces curly with dollar quotes.
Also, a couple of new operators appeared:
-In and -NotIn , indicating a range. With them, I think, more than understandable:
Custom session configurations
The most remarkable innovation that I want to talk about in the first part is the configuration of the session in conjunction with the delegation of administrative powers. The actual configuration file is a file with the .pssc extension, which only contains a hash table of properties and values: authorship, language, variables, function definitions, and so on. There are other properties in the session configuration itself:
Get-PSSessionConfiguration | Get-Member
A picture similar to this one will appear:
See how many customizable parameters? You can even compare with the picture that appears when you run this command in PowerShell v2 and feel the difference.
But how to use it? And now I will show, I confess, I was picking long enough to write these few lines. So, we consistently execute:
$defSSDL = (Get-Item WSMan:\localhost\Service\RootSDDL).Value # SSDL " " $SecDescriptor = New-Object -TypeName Security.AccessControl.CommonSecurityDescriptor $false, $false, $defSSDL # $user = Get-ADUser "user1" # Active Directory , , , $SecDescriptor.DiscretionaryAcl.AddAccess([System.Security.AccessControl.AccessControlType]::Allow, $user.SID.Value, 268435456, [System.Security.AccessControl.InheritanceFlags]::None, [System.Security.AccessControl.PropagationFlags]::None) # SID $sddl = $SecDescriptor.GetSddlForm("All") # , $creds = Get-Credential "administrator@litware.inc" # New-PSSessionConfigurationFile -Path .\DnsRead.pssc -SessionType RestrictedRemoteServer -VisibleCmdlets "Show-DnsServer*" -ModulesToImport DnsServer # Register-PSSessionConfiguration -Name DnsRead -Path .\DnsRead.pssc -AccessMode Remote -SecurityDescriptorSddl $sddl -RunAsCredential $creds #
Notice, I limited the configuration to the
DnsServer module and only to cmdlets starting on Show-DnsServer , this ensures that although the shell itself will run with the privileges of user administrator@litware.inc , the remote user user1 from the remote machine w2012cl1 cannot do anything except perhaps for this:
Convenient thing, right? By limiting the modules and cmdlets inside PowerShell, we can easily and naturally, within our team of administrators, make some employees responsible for the DNS, others for the network, and users, for example, to give the right to make snapshots of their Hyper-V machines inside VDI, and no one know the credentials of the user from which the task is performed! And the ready configuration file is simply transferred from one place to all other servers with similar functions.
In the next part we will go further, or rather up the list, analyze the reliable sessions, scheduled tasks and, of course, workflows. Well, and, perhaps, a little touch on the new PowerShell ISE, there is also something to look at.
Source: https://habr.com/ru/post/146247/
All Articles