Windows Server 2012 - life without GUI
Windows Server 2012 is positioned as a system that does not need a GUI for full-fledged work. When installing, the Server Server option is selected by default, the ability to remove the graphical interface without reinstalling the server is added, the list of roles that do not need a GUI is expanded compared to 2008 R2. In his books, Microsoft claims that working with the command line is natural and recalls the beginning of the 90s of the last century, when system administrators complained about the useless waste of resources by the graphical shell. In addition, Microsoft offers a “new” way to administer its server operating systems, in which it is assumed that you will only see the server console once - when installing the operating system, and all the work and configuration of the system will be done remotely: through the Server Manager , MMC-snap-ins and PowerShell, which in 2012 server is already version 3.0
Suppose that the initial server setup after installation includes:
The question is: can these tasks be performed remotely using PowerShell? Well, let's say, there is a remote server somewhere in the taiga, on which the local craftsman put the 2012 server, went to mark this case and lost the key to the cabinet. The case is armor-piercing, waterproof, soundproof and generally involves protection against unauthorized access by bears. And you need to configure. Suppose there is a VPN or some kind of "direct wire" (I often see this service in the price lists of providers) and the server is available over the network. And only on the network.
')
In the source data a letter from a local craftsman:
Hi, put Venda on the server. IP - 169.254.23.43. Login - Administrator. The password is qwe123! @ #. Until.
The remote server in the workgroup, in a freshly installed state, does not understand RPC (the ports on the firewall are closed), does not ping, with an unprovable name and Moscow time zone in Siberia. If this were 2008 R2, our adventures would end there, since all remote controls in it are disabled by default. In 2012, there is a way to remotely control out of the box — WinRM enabled by default, an implementation of the Microsoft WS-MAN standard. On the one hand, it seems to be a security hole, on the other hand, in a normally designed network in which the servers are located in a separate VLAN, access to which is restricted to trusted users, the probability of using this hole is negligible. But still there.
To manage a remote server in a workgroup using WinRM, we must trust the remote server. Here the logic is a little incomprehensible to me. The idea is that the remote server should trust us, we manage it, and not us. Perhaps this is from an incomplete understanding of how WS-MAN works. But in any case, tell WinRM that we trust the remote server needs. This is implemented by entering the name or IP address of the remote server in the list of "trusted hosts" (TrustedHosts)
Now somehow you need to perform the initial configuration of the remote server. I know 2 cmdlets that can help with this task: Enter-Pssession and Invoke-Command . Both use WinRM. Enter-Pssession gives us the console of a remote server, Invoke-Command sends a block of commands to a remote server and returns the result of their execution. Below, Invoke-Command is used (we are not going to see the remote console at all).
Actions will be performed on the following principle:
There is nothing to do, we change our address to something from the APIPA-range, for example, well, 169.254.0.1 and sit down to think how to remotely change the IP address of the taiga server. There is nothing to think about:
And all this is desirable without uncoupling from the server.
In PowerShell 3.0, there is a whole group of Network Adapter Cmdlets , which allows us to do anything with network adapters.
Obtain the network adapter object and save it in the $ adapter variable. Ethernet is the new name for “Local Area Connection”. This change, despite the seeming insignificance, is very pleasing.
Disable DHCP
Change the IP address to normal with the necessary mask and gateway. For this there is another group Net TCP / IP Cmdlets
Add DNS servers. Third group DNS Client Cmdlets
How to do all this on a remote server? Make a script and use Invoke-Command to run it.
Let's save this command set somewhere with the name of the script, for example, remotechangeip.
We send our script to a remote server.
We have the password for the Administrator account in the letter. After execution, we get a server with a static address 192.168.0.5 with a subnet mask / 24, a default gateway 192.168.0.1, and DNS servers 192.168.0.2 and 192.168.0.3
You also need to remember to change the IP in TrustedHosts, otherwise our remote administration will end there.
I tried to solve this problem for a very long time using PowerShell. I found a function that changes the time zone locally. But if we try to execute this function through Invoke-Command, we will get a rake across the forehead in the form "The name Set-Timezone is not recognized as the name of a cmdlet, function, script file or program being executed."
Invoke-Command, when executed naturally, does not copy from the local machine, but executes cmdlets that are available on the remote server. This is understandable and logical. The task was clear - before performing Invoke-Command, you need to reset the function to a remote server. But ... then I was too lazy.
If you look into the function code, it becomes clear that it only checks the OS version and, depending on it, either performs timedate.cpl (XP and lower) or tzutil (Vista and higher). There is no need to check the OS version, we know it. So just change the time zone with tzutil
Values ​​of time zones can be taken from here or from the output tzutil / l
Well, without PowerShell still not done.
In PowerShell 3.0, many cmdlets have appeared to work with RDS. Their group is called Remote Desktop Cmdlets. But, as I understand it, they are designed to work with an RDS server, you simply cannot enable the remote desktop for the administrator with their help.
There are two ways to turn on the desktop. Through WMI calls andincorrect through registry modification. I never liked modifying the registry. One awkward finger movement and no one guarantees that the server will rise after a reboot.
As for the inclusion of a remote desktop, modifying the HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ fDenyTSConnections key , which needs to be set to 0 to allow the remote desktop:first, it requires a reboot, second , it does not add an exception to remote desktop in firewall rules.
Therefore, I will use the WMI class win32_terminalservicesetting and its setallowtsconnections method, which will allow you to do without rebooting and add exception rules in the firewall with one command.
Now we have access to the taiga server via RDP! Can you rejoice? Imagine that the only channel of communication with the outside world is at the remote server via satellite with extortionate tariffs, dial-up speed, through-the-top ping and continue to configure the server remotely via PowerShell.
All the more, that remained quite a bit.
In theory, the Add-Computer cmdlet allows you to rename a computer when it joins a domain. But in practice, I was faced with the fact that when joining a domain and simultaneously renaming it using this command, the computer enters the domain under its old name. And it raced - to bring the computer out of the domain, reboot, delete the account in AD, start replication if there are several controllers, wait, rename the computer, reboot, enter into the domain, reboot.
Therefore, I prefer to rename the computer and enter the domain separately.
Rename
As soon as the control is returned to us, the remote server is rebooted. You can check the result of the command (and server readiness) like this:
And finally entering the domain
All tasks set at the beginning are completed. Now you can think about how to continue to live and where to find this damn key to the cabinet.
And finally, a small cheat sheet on CMD and PowerShell.
One thing unites them: they all need RPC for remote work, which by default is closed by a firewall. Therefore, the only way to deliver them to a remote computer is WinRM.
And Enter-Pssession did not work for me :)
Used material from:
MSDN
Technet
Suppose that the initial server setup after installation includes:
- Network Interface Setup
- Setting the time zone
- Enable Remote Desktop
- Rename computer
- Joining a domain
The question is: can these tasks be performed remotely using PowerShell? Well, let's say, there is a remote server somewhere in the taiga, on which the local craftsman put the 2012 server, went to mark this case and lost the key to the cabinet. The case is armor-piercing, waterproof, soundproof and generally involves protection against unauthorized access by bears. And you need to configure. Suppose there is a VPN or some kind of "direct wire" (I often see this service in the price lists of providers) and the server is available over the network. And only on the network.
')
In the source data a letter from a local craftsman:
Hi, put Venda on the server. IP - 169.254.23.43. Login - Administrator. The password is qwe123! @ #. Until.
Getting ready
The remote server in the workgroup, in a freshly installed state, does not understand RPC (the ports on the firewall are closed), does not ping, with an unprovable name and Moscow time zone in Siberia. If this were 2008 R2, our adventures would end there, since all remote controls in it are disabled by default. In 2012, there is a way to remotely control out of the box — WinRM enabled by default, an implementation of the Microsoft WS-MAN standard. On the one hand, it seems to be a security hole, on the other hand, in a normally designed network in which the servers are located in a separate VLAN, access to which is restricted to trusted users, the probability of using this hole is negligible. But still there.
To manage a remote server in a workgroup using WinRM, we must trust the remote server. Here the logic is a little incomprehensible to me. The idea is that the remote server should trust us, we manage it, and not us. Perhaps this is from an incomplete understanding of how WS-MAN works. But in any case, tell WinRM that we trust the remote server needs. This is implemented by entering the name or IP address of the remote server in the list of "trusted hosts" (TrustedHosts)
si WSMan:\localhost\Client\TrustedHosts 169.254.23.43 Now somehow you need to perform the initial configuration of the remote server. I know 2 cmdlets that can help with this task: Enter-Pssession and Invoke-Command . Both use WinRM. Enter-Pssession gives us the console of a remote server, Invoke-Command sends a block of commands to a remote server and returns the result of their execution. Below, Invoke-Command is used (we are not going to see the remote console at all).
Actions will be performed on the following principle:
- Powershell
- If you can't complete the task via PowerShell, connect cmd
- If not in PowerShell, not in cmd there are no suitable tools - WMI via PowerShell
- Well, as the last option - picking the registry also via PowerShell
Network Interface Setup
There is nothing to do, we change our address to something from the APIPA-range, for example, well, 169.254.0.1 and sit down to think how to remotely change the IP address of the taiga server. There is nothing to think about:
- Determine on which adapter to make changes
- Disable DHCP
- Assign a static address for the server with a subnet mask and default gateway.
- Assign DNS servers
And all this is desirable without uncoupling from the server.
In PowerShell 3.0, there is a whole group of Network Adapter Cmdlets , which allows us to do anything with network adapters.
Obtain the network adapter object and save it in the $ adapter variable. Ethernet is the new name for “Local Area Connection”. This change, despite the seeming insignificance, is very pleasing.
$adapter = Get-NetAdapter Ethernet Disable DHCP
$adapter | Set-NetAdapter –Dhcp disabled Change the IP address to normal with the necessary mask and gateway. For this there is another group Net TCP / IP Cmdlets
$adapter | New-NetIPAddress 192.168.0.5 –PrefixLength 24 –DefaultGateway 192.168.0.1 Add DNS servers. Third group DNS Client Cmdlets
Set-DnsClientServerAddress Ethernet –addresses (“192.168.0.2”,”192.168.0.3”) How to do all this on a remote server? Make a script and use Invoke-Command to run it.
Let's save this command set somewhere with the name of the script, for example, remotechangeip.
There is one moment. The script execution policy is called.
By default, PowerShell is allowed to work only in interactive mode, the execution of any scripts is prohibited (restricted). To execute the scripts, we need either remotesigned (a digital signature is required for scripts downloaded from the Internet), or unrestricted (when executing an unsigned script downloaded from the Internet, a warning about the unreliability of the source will be issued). If you completely put on safety, you can put a bypass (everything will be done without any extra questions). If you have your own certificate issued by a trusted publisher, and you are not lazy to sign your scripts with it - you need allsigned (in this case, you probably know it yourself). I do not have a certificate, so I install the remotesigned policy.
The script execution policy is installed on the local computer; there is no such need on the remote one, because Invoke-Command converts the script file into just a set of commands before executing the script on the remote computer. Accordingly, a script (a file with the .ps1 extension) is executed on the remote computer, but a set of commands with which the execution policy of scripts is on the drum.
Set-ExecutionPolicy remotesigned The script execution policy is installed on the local computer; there is no such need on the remote one, because Invoke-Command converts the script file into just a set of commands before executing the script on the remote computer. Accordingly, a script (a file with the .ps1 extension) is executed on the remote computer, but a set of commands with which the execution policy of scripts is on the drum.
We send our script to a remote server.
Invoke-Command 169.254.23.43 C:\scripts\remotechangeip.ps1 –Credential We have the password for the Administrator account in the letter. After execution, we get a server with a static address 192.168.0.5 with a subnet mask / 24, a default gateway 192.168.0.1, and DNS servers 192.168.0.2 and 192.168.0.3
You also need to remember to change the IP in TrustedHosts, otherwise our remote administration will end there.
$newvalue = ((ls WSMan:\localhost\Client\TrustedHosts).value).replace("169.254.23.43","192.168.0.5") si WSMan:\localhost\Client\TrustedHosts $newvalue Change time zone
I tried to solve this problem for a very long time using PowerShell. I found a function that changes the time zone locally. But if we try to execute this function through Invoke-Command, we will get a rake across the forehead in the form "The name Set-Timezone is not recognized as the name of a cmdlet, function, script file or program being executed."
Invoke-Command, when executed naturally, does not copy from the local machine, but executes cmdlets that are available on the remote server. This is understandable and logical. The task was clear - before performing Invoke-Command, you need to reset the function to a remote server. But ... then I was too lazy.
If you look into the function code, it becomes clear that it only checks the OS version and, depending on it, either performs timedate.cpl (XP and lower) or tzutil (Vista and higher). There is no need to check the OS version, we know it. So just change the time zone with tzutil
Invoke-Command 192.168.0.5 {tzutil /s “North Asia Standard Time”} –Credential WMI
You can try to set the time zone using WMI. It will look like this:
What's going on here? The dot (.) Says that we are working with a local computer. We turn on the local computer to the class win32_computersystem . Set the CurrentTimeZone property to 207, corresponding to “North Asia Standard Time”. And the Put method saves the time zone change.
Also save and transfer the script to the remote computer using Invoke-Command. In my opinion, tzutil is easier to use.
$strComputer = "." $objWMI = gwmi win32_computersystem" -computername $strComputer $objWMI.CurrentTimeZone = 207 $objWMI.Put() What's going on here? The dot (.) Says that we are working with a local computer. We turn on the local computer to the class win32_computersystem . Set the CurrentTimeZone property to 207, corresponding to “North Asia Standard Time”. And the Put method saves the time zone change.
Also save and transfer the script to the remote computer using Invoke-Command. In my opinion, tzutil is easier to use.
Values ​​of time zones can be taken from here or from the output tzutil / l
Well, without PowerShell still not done.
Enable Remote Desktop
In PowerShell 3.0, many cmdlets have appeared to work with RDS. Their group is called Remote Desktop Cmdlets. But, as I understand it, they are designed to work with an RDS server, you simply cannot enable the remote desktop for the administrator with their help.
There are two ways to turn on the desktop. Through WMI calls and
As for the inclusion of a remote desktop, modifying the HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ fDenyTSConnections key , which needs to be set to 0 to allow the remote desktop:
Therefore, I will use the WMI class win32_terminalservicesetting and its setallowtsconnections method, which will allow you to do without rebooting and add exception rules in the firewall with one command.
Invoke-Command 192.168.0.5 {(gwmi win32_terminalservicesetting -namespace root\cimv2\terminalservices).setallowtsconnections(1,1)} –Credential Now we have access to the taiga server via RDP! Can you rejoice? Imagine that the only channel of communication with the outside world is at the remote server via satellite with extortionate tariffs, dial-up speed, through-the-top ping and continue to configure the server remotely via PowerShell.
Rename the server and join it to the domain
All the more, that remained quite a bit.
In theory, the Add-Computer cmdlet allows you to rename a computer when it joins a domain. But in practice, I was faced with the fact that when joining a domain and simultaneously renaming it using this command, the computer enters the domain under its old name. And it raced - to bring the computer out of the domain, reboot, delete the account in AD, start replication if there are several controllers, wait, rename the computer, reboot, enter into the domain, reboot.
Therefore, I prefer to rename the computer and enter the domain separately.
Rename
Invoke-Command 192.168.0.5 {rename-computer taiga -restart} -credential As soon as the control is returned to us, the remote server is rebooted. You can check the result of the command (and server readiness) like this:
Invoke-Command 192.168.0.5 {$env:computername} -credential And finally entering the domain
Invoke-ommand 192.168.0.5 {add-computer contoso.com -credential contoso.com\domainadmin -restart} -credential We finish
All tasks set at the beginning are completed. Now you can think about how to continue to live and where to find this damn key to the cabinet.
And finally, a small cheat sheet on CMD and PowerShell.
| Cmd | Powershell | |
| Change network settings | | |
| Change time zone | | |
| Enable Remote Desktop | | |
| Rename server | | |
| Join Domain | | |
One thing unites them: they all need RPC for remote work, which by default is closed by a firewall. Therefore, the only way to deliver them to a remote computer is WinRM.
And Enter-Pssession did not work for me :)
Used material from:
MSDN
Technet
Source: https://habr.com/ru/post/183012/
All Articles