Figure 17.1 Getting to the System Properties dialog box
The day-to-day administration of any server rarely occurs at the server. Instead, administrators commonly connect to servers remotely.
The servers are humming along smoothly in a cool (and sometimes downright cold) server room protected with physical security. Administrators are often in a comfortable office running a desktop system like Windows 7 or Windows 8. When administration is necessary, they connect to the servers remotely.
With this in mind, you need to know how to configure the servers for remote administration and connect to the servers from your desktop. Either that, or you will spend your time in the server room bundled up in a parka in the middle of the summer.
In this chapter, you will learn to:
Remote Desktop for Administration is the default implementation of Remote Desktop Services (RDS) on a Windows Server 2012 R2 server. In this mode, as many as two administrators can be remotely logged onto a server at the same time performing remote administration.
It’s also possible to configure a server as a Remote Desktop Session Host server so that it can run desktops or desktop applications for remote users. However, configuring the server as a Remote Desktop Session Host server requires additional licenses and a licensing server. When using the server in the Remote Desktop for Administration mode, no additional licensing is required.
Remote Desktop for Administration allows you to connect to a server and do just about anything remotely that you could if you were physically at the server. You can access the Start menu, launch tools, install applications, install updates, and do much more when connected remotely. The two primary tools you’ll use are Remote Desktop Connection and Remote Desktop.
The primary limitation you have is if the remote system needs a reboot or restart. Although it is possible to reboot the system remotely, when you do so, you will be disconnected. If something prevents the system from rebooting, you won’t know what the problem is or be able to resolve it.
You can enable Remote Desktop on the server in several ways. You can access the advanced properties page of the server by one of the following methods:
Figure 17.1 Getting to the System Properties dialog box
Figure 17.2 shows the configuration choices you have on the Remote tab.
Figure 17.2 Configuring Remote Desktop from the Remote tab of the System Properties dialog box
You can see that Windows Server 2012 R2 provides three choices for configuring the server for remote administration:
When you enable Remote Desktop Connection, an exception is automatically created in the firewall on the local system. It’s not necessary to add other exceptions on the local firewall. However, if you connect through a network firewall, port 3389 needs to be opened to allow the remote connections through. If opening port 3389 on your network firewall is not feasible in your network, you can create a Remote Desktop Gateway server as described later in this chapter.
Network Level Authentication (NLA) is a security feature available in Remote Desktop Services when the more secure setting is selected. NLA provides added security by completing the user authentication before the remote connection is established. If NLA is not used, the server is vulnerable to a denial-of-service attack.
NLA should be used whenever possible. The following are the requirements to support NLA:
Remote Desktop Connection (RDC) is used to connect to a remote server. The version that works best with Windows Server 2012 R2 is RDC 6.0 or greater. Earlier versions don’t support all of the features available, such as NLA.
You can launch RDC in Windows Vista, Windows 7, and Windows Server 2008 R2 by selecting Start 
All Programs Accessories Remote Desktop Connection. Once RDC is launched, you can click the Options button to view all the options available, as shown in Figure 17.3.
Figure 17.3 Remote Desktop Connection with Options expanded
Accessing RDC on Windows 8 and Windows Server 2012 R2 is a little different:
Figure 17.4 Getting to RDC on Windows Server 2012 R2
RDC includes six tabs that can be manipulated to provide different features, as detailed in the following sections.
The General tab is used to identify the remote computer you want to connect with and the user account you’ll use to connect. Additionally, you can save your settings in a Remote Desktop Protocol file from this page.
By saving your settings in an RDP file, you can simply double-click the file to start the session. Follow these steps to save and use your RDP file:
Figure 17.5 Remote Desktop Connection unknown publisher warning
Figure 17.6 Remote Desktop Connection unknown certifying authority warning
The RDP file is associated with the Remote Desktop Connection application, so by double-clicking it, you will launch RDC. However, this RDP file is simply a text file. If you want to look at the contents, you can launch Notepad and browse to the file to see the contents.
The Display tab allows you to configure the display for the remote desktop. You can configure the size of the desktop and the colors from this page. Figure 17.7 shows the Display tab.
Figure 17.7 Remote Desktop Connection Display tab
If you drag the slider all the way to the right, the remote desktop will display in full-screen mode. By default, a connection bar will be displayed across the top when in full-screen mode.
The connection bar includes the name of the remote server, which can be useful if you have more than one instance of RDC running at a time. For example, if you’re troubleshooting a problem and remote into three different servers using three different instances of RDC, you can quickly glance at the connection bar at the top of the window to remind yourself which server you’re accessing.
When you remote into a server using RDC in full-screen mode, this connection bar is the only apparent difference you’ll see. Everything else will look as if you’re standing in front of the server.
At the left of the connection bar is a pushpin icon. It is selected by default and pins the connection bar to the top of the screen. You can deselect it to enable autohiding of the connection bar.
The Local Resources tab allows you to identify what resources you can bring to your remote session. For example, if you have a printer attached to your system and you want to print a log from the remote server, you can enable the local printer.
Microsoft introduced Easy Print in Windows Server 2008, which makes printer redirection easier with Remote Desktop Services and ensures that the client printers are installed in remote sessions. You don’t have to install the print drivers on the server in order to print from an RDS session.
You can click the More button to enable additional resources during the remote session. Figure 17.8 shows the Local Resources tab and the additional resources that can be enabled after clicking the More button.
Figure 17.8 The Remote Desktop Connection Local Resources tab, with additional options
The primary reason why you’ll access this tab is to enable or disable local devices and resources. Local printers and the local clipboard are enabled by default. The local clipboard allows you to copy text from your system (such as a script) and paste it into an application in the remote session.
Local drives are not enabled by default, but if you want to copy data from a local drive to the remote system, you can easily select the box. This does represent a security risk, though. If either the remote system or your local system is infected with malware, connecting the drives makes them accessible by the malware and susceptible to infection.
You can also configure the audio and keyboard settings. Audio settings include the following:
If you’re a fan of keyboard shortcuts, you may want to change the keyboard settings. The choices are as follows:
The Programs tab allows you to identify a program that will start when the remote connection is established. For example, you may always launch Server Manager when you start a specific server and want it to start automatically.
Figure 17.9 shows the RDC Programs tab. ServerManager.msc is entered in the text box, which will cause Server Manager to start when the connection is created.
Figure 17.9 Remote Desktop Connection Programs tab
Since the path of Server Manager is already known by the system to be %systemroot%\System32, the path doesn’t need to be included. However, if you wanted to launch a different program or script from an unknown path, you would need to include the full path.
You can add or remove different features from the RDC Experience tab. Different features such as the desktop background, menu and window animations, and visual styles are available to enhance the remote connection’s display or experience.
Figure 17.10 shows the RDC Experience tab with the connection speed set to “LAN (10 Mbps or higher).” These features take additional bandwidth, so default features are selected based on the connection speed selected on this page.
Figure 17.10 Remote Desktop Connection Experience tab
If you’re connected in a local LAN, you have high-speed connectivity, so all of the features are available. If you see a decrease in performance, you can deselect some of the features. Additionally, if you connect using a modem over a 56 Kbps connection, you could select the Modem (56 Kbps) setting, and only persistent bitmap caching will be enabled by default.
The speed selection isn’t automatically determined. When it is selected, default features are selected, but you can easily add or remove these features by selecting or deselecting the corresponding check boxes.
This page also includes the setting “Reconnect if the connection is dropped.” This is useful on unreliable links. If the network connection is dropped, RDC will automatically try to reconnect.
The RDC Advanced tab includes two sections: “Server authentication” and “Connect from anywhere.”
Server authentication is a new security feature available when connecting to Windows Server 2008 or later servers. It provides verification that you are connecting to the computer that you intended to connect to, and it helps prevent the unintentional disclosure of confidential information.
You have three choices with server authentication:
Figure 17.11 shows the Remote Desktop Connection Advanced tab with the Remote Desktop Gateway (RD Gateway) settings expanded.
Figure 17.11 Remote Desktop Connection Advanced tab and Remote Desktop Gateway settings
If you are connecting to a remote server through an RD Gateway server, you will configure the connection settings here. RD Gateway will be covered in more detail later in this chapter.
The important thing to realize is that the server name you enter here is that of the gateway server. RDC will connect to this RDC server first and then to the remote server identified on the General tab.
You will need to authenticate with both the RD Gateway server and the remote computer. If you use the same credentials for both, you can leave the “Use my RD Gateway credentials for the remote computer” check box selected. With this check box selected, you will be challenged only once. If you deselect it, you will be challenged at both servers, and you can enter different credentials for each.
Although knowing what each of the tabs within the Remote Desktop Connection can do for you is useful, you’ll want to know some other details. For example, you can launch it from the command line, and with any command-line command, there are useful switches to master. Additionally, you can control several different limitations on remote connections.
You can launch the Remote Desktop Connection from the Run line or the command line using the mstsc.exe command. The name mstsc is derived from Microsoft Terminal Services Connection. Even though Terminal Services has been renamed to Remote Desktop Services, the mstsc command is still the same.
You can access the help screen for mstsc by entering mstsc /? at the command line. The following items show some of the common usages for mstsc:
Only two connections are allowed to the server when it is used for normal administrative connections. In other words, only two administrators can be logged onto a single server at a time.
If the server is used to host desktops or applications for end users, then you can have as many connections as you need. Remote Desktop Services requires licenses for connections when used in Remote Desktop session host server mode. However, licenses are not required for the two administrator connections.
The two connections include either remote sessions or the session at the computer. Previous operating systems allowed you to connect to two remote sessions and the session at the computer. The session at the computer was referred to as the console session and you were even able to connect to this console session remotely, but the console session is no longer available.
Figure 17.12 shows the result if a third user tries to connect when two sessions are already active.
Figure 17.12 Blocking the third remote session
In the figure, a user named Darril is physically located at the server and logged on. Sally is connected via a remote session. Joe tries to log on, but since his session will be the third session, it is blocked. Notice that the dialog box also indicates whether these sessions are active or idle. In the figure, Sally’s session has been idle for 11 minutes, and Darril’s session is active.
If Joe selects the check box next to “Force disconnect of this user” and selects one of the users, that user will be immediately disconnected with a message saying this:
Your Remote Desktop session has ended. Another user connected to the remote computer so your connection was lost. Try connecting again, or contact your network administrator or technical support group.
If Joe doesn’t select the check box but instead just selects one of the users to disconnect the session, the user will get a notification. Figure 17.13 shows what appears on Darril’s session when Joe tries to disconnect it without the check box selected. If Darril is working at the computer, he can see this connection attempt and click Cancel to block it. Otherwise, the request will automatically disconnect Darril’s session after 30 seconds and allow Joe’s session.
Figure 17.13 Disconnect request
If Darril was active and clicked Cancel, Joe would receive a notification indicating that the logged-on user denied the disconnect request.
For the next few sections of this chapter you will need the Remote Desktop Services role installed on the server.
To install this role, do the following:
Figure 17.14 Select the type of role installation
Figure 17.15 Select the server on which to install the RDS role.
Figure 17.16 Selecting the Remote Desktop Services role
Figure 17.17 Features selection screen
Figure 17.18 Role summary screen
Figure 17.19 Selecting role services
Figure 17.20 Network Policy and Access Services notification
Figure 17.21 Network Policy Server
Figure 17.22 Role Confirmation page
Figure 17.23 Installation progress
In Windows Server 2012 R2, you can no longer use the Remote Desktop Session Host Configuration Tool that you may have used in Windows Server 2008 R2.
You can configure session properties for remote sessions in the Remote Desktop Session Host from within Group Policy Management Editor. You can access this tool by hitting your Windows key and choosing Group Policy Management.
The primary configuration you’ll use here when using Remote Desktop Services is the Remote Desktop Session Host. Figure 17.24 shows the properties available for Remote Desktop Session Host.
Figure 17.24 Using Group Policy Manager to configure Desktop Session Host
Since there are so many properties listed, we just discuss a couple of important ones you should be concerned with.
Although the Remote Desktop Connection is an extremely valuable tool to remotely administer servers within a controlled LAN, sometimes it won’t meet your needs. For example, you may want to remotely connect to a server over the Internet, but the firewall administrators simply refuse to open the ports. Remote Desktop Gateway may be exactly what you need.
RD Gateway is used to allow connections to an internal network via the Internet. When RD Gateway is enabled, users can connect to resources on an internal network from any Internet-connected device. RD Gateway works the same way whether it’s used to allow an administrator to access an internal resource or to allow a regular user to access a Session Host server, as covered in Chapter 29, “Installing, Using, and Administering Remote Desktop Services.”
RD Gateway uses the Remote Desktop Protocol over HTTPS to establish a secure, encrypted connection between the remote users and the internal resource.
Figure 17.25 shows how RD Gateway could be configured. A Windows Server 2012 R2 server named BF4 is placed in the DMZ with the Remote Desktop Gateway role service installed. The client can connect to BF4 over the Internet using RDP over HTTPS.
Figure 17.25 RD Gateway providing access to an internal server
HTTPS uses Secure Sockets Layer (SSL) to encrypt the session and uses port 443. The external firewall needs port 443 open to support the HTTPS traffic.
BF4 will authenticate the client and act as the gateway to internal resources. RD Gateway can be configured with a resource authorization policy to restrict access to a single server (such as BF2 in the figure) or any resources in the network.
Remote Desktop Connection Authorization Policies (RD CAP) are used to restrict who can connect to the RD Gateway server. Remote Desktop Resource Authorization Policies (RD RAP) are used to restrict which servers can be accessed once a user connects.
In past versions of Windows, it was possible to remotely administer servers from the Internet. However, you had to open port 3389 on the firewall (or convince the firewall administrator to open the port). But every additional port opened on a firewall represents an additional vulnerability that needs to be managed.
From a security standpoint, it’s much easier to simply leave the port closed. Even though remote administration through port 3389 was a useful feature, it was often blocked at the network firewall to mitigate the associated security risks.
Since RD Gateway uses RDP over HTTPS through port 443, the external firewall needs only port 443 open. Port 443 is commonly open to allow other HTTPS traffic through. If port 443 is open for other HTTPS traffic, you don’t need to open additional ports to use RDP over HTTPS.
As an example, if a company was hosting a web server using HTTP and HTTPS, ports 80 and 443 would be open to support the web server. You can then implement RD Gateway on a server in the DMZ without modifying the firewall.
Even if port 443 isn’t already open, the security of HTTPS is well understood by most administrators. It’s easier for an administrator to weigh the risks of HTTPS and make a decision to open this port than it is to consider opening port 3389 for remote administration traffic.
RD Gateway supports connections from Remote Desktop Connection 6.0 or greater. However, to support all the features available in RD Gateway in Windows Server 2012 R2, Remote Desktop Protocol 8.0 is recommended. This is natively provided in the RDC client supplied with Windows 8 and Windows 2012. The RDP 8.0 client is also available as an add-on for Windows 7 SP1 and Windows Server 2008 R2 SP1 (http://support.microsoft.com/kb/2592687).
Although these features are most useful when using Remote Desktop Services to host desktops and remote applications, administrators may find them useful too. These are some of the additional features that are available:
RD Gateway requires the following additional role services and features on the Windows Server 2012 R2 server where it is hosted (which we had you install earlier in this section):
When you add the RD Gateway role, the wizard will prompt you to automatically install all the required roles, services, and features. You won’t need to install them individually. However, if they are already installed, the wizard will recognize that they are active.
Before users can connect through RD Gateway, you must have at least two policies:
Follow these steps to enable the Remote Desktop Gateway role service on a Windows Server 2012 R2 server. These steps will also lead you through adding the required roles, services, and features, as well as RD CAP and RD RAP:
After a few minutes and a server reboot, you should have RD Gateway installed on your server. To access it you can hit your Windows key. You will see a new Metro-style button called Remote Desktop Gateway, as shown in Figure 17.26.
Figure 17.26 Remote Desktop Gateway
Once you get inside the RD Gateway Manager, you can see that it’s very similar to the Group Policy Management tool. You can manage all aspects of the RD Gateway using this tool.
On the left window pane you will see your server with two folders underneath: Policies and Monitoring. If you click the server you will see current connection information and any outstanding configurations required, as shown in Figure 17.27.
Figure 17.27 Gateway connection information
As you can see in Figure 17.27, we still need to configure the Gateway certificate.
Figure 17.28 Create your self-signed certificate.
You can see in Figure 17.29 that our certificate has installed successfully.
Figure 17.29 Certificate installed properly
Figure 17.30 shows that we still have a few configuration items to attend to. The first one is Remote Desktop Connection Authorization Policy, and the other is Remote Desktop Resource Authorization Policies. For those of you familiar with Windows Server 2008 R2, you may have noticed that all three of these, starting with the certificate, are configured during the installation of the Remote Desktop Services role. In Windows Server 2012 R2 they get configured in Gateway Manager.
Figure 17.30 Requirements needed to complete gateway configuration
Figure 17.31 Enter a policy name.
Figure 17.32 Requirements tab
Figure 17.33 Device Redirection tab
Figure 17.34 Timeouts tab
Your newly created policy will now show up in the Connection Authorization Policy window. You will also notice that the requirement on the Gateway property has been fulfilled.
As we mentioned earlier, we also need to set the Remote Desktop Resource Authorization Policy. This will fulfill the last requirement to setting up the Remote Desktop Gateway. This is very similar to the procedure you just completed for RD CAP:
Figure 17.35 Add a policy name and description.
Figure 17.36 Add a group to the User Groups tab.
Figure 17.37 Network Resource tab
Figure 17.38 Allow Ports tab
Congratulations! Your gateway is now configured and ready to allow connections.
Remote Desktop Connection and Remote Gateway are both valuable tools used to remotely administer servers. However, each of these will launch as single instances. There may be times when you’re charged with managing multiple servers and you want to manage them through a single tool. Remote Desktops is your solution.
Remote Assistance is primarily a feature used on desktop systems and is not enabled by default on Windows Server 2012 R2. However, if you have a large organization with junior administrators in remote locations, it can be very useful to you.
For example, imagine you work at the main location of your company and your company has a remote office with only 20 people. One of these employees occasionally performs routine tasks on the server located in the remote office but may need some help. With Remote Assistance enabled, they can send you a request for assistance. You can then access the remote server’s desktop and demonstrate how to perform a task.
The Remote Assistance check box in System Properties is grayed out and can’t be enabled until the Remote Assistance feature is added to Windows Server 2012 R2. The following steps show how to enable Remote Assistance:
With the Remote Assistance feature added, Remote Assistance should now be enabled on the server. You can verify it with these steps:
This server is now configured for Remote Assistance. To start a Remote Assistance session, the user needs to send a Remote Assistance request.
The user who needs assistance should follow these steps to create a Remote Assistance request and begin the process:
At this point, the person needing help must wait for the response from the helper.
The helper can follow these steps with the person requesting assistance to begin a Remote Assistance session:
The helper can now control the mouse on the remote computer. Figure 17.39 shows the Windows Remote Assistance window viewed by the person being helped.
Figure 17.39 Remote Assistance session on a remote computer
At this point, the helper can manipulate the mouse and keyboard of the remote desktop to demonstrate any tasks. This is shared control. In other words, both the helper and the user have control over the desktop.
It’s useful if the helper and user are able to talk over the phone during this process, but it’s not necessary. The Windows Remote Assistance dialog boxes include a Chat feature that allows each of the users to type questions and comments.
The helper could demonstrate a task and then simply type “now you try it” while observing the desktop. The helper could stop using the mouse, and the user could perform the same steps on their computer. Additionally, the user being helped can end the session whenever they want to by clicking Stop Sharing or Pause.
The Windows Remote Management Service (WinRM) will allow you to issue any command-line command from one computer against a remote computer.
For example, you may be working on a Windows 7 or Windows 8 computer, but you want to query some information from a remote server. If the server has been configured with WinRM, you can execute a WinRS command-line command from the desktop system and get the results just as if you were at the computer or connected with RDC.
One of the benefits of this is that you don’t need to consume one of the two remote sessions for a server or even launch RDC. You can simply enter the command at your command prompt.
The following are the two commands used by the Windows Remote Management Service:
WinRM is not enabled by default on Windows Server 2012 R2. You can use the following steps to enable WinRM on the server.
WinRM qcWinRM enumerate WinRM/config/listenerWinRM e WinRM /config/listenerWinRM e WinRM /config/listener -format:#text
WinRM e WinRM /config/listener -format:#xml
WinRM e WinRM /config/listener -format:#prettyAlthough there is more you can do with WinRM on the server, its primary purpose for remote administration is to enable the listener with the quickconfig command. Once this is done, you’ll probably turn your attention to the client where you’ll do the actual administration.
The Windows Remote Shell (WinRS) is used to execute commands against a remote server that has been configured with WinRM. For example, you could use WinRS from a Windows 7 or Windows 8 system to execute commands against a remote server.
WinRS commands are primarily formatted as follows:
WinRS -r:servername commandThe -r switch is used to identify the name of the remote server. Although other switches are available, the -r switch is the switch used the most.
WinRS commands can be any command that you would issue from the command line. As an example, you can use the Windows Management Instrumentation Command-line (WMIC) tool to document the services running on computers.
Before using WinRS, you can use this command to show how WMIC can be used to document information on services running on any system. Launch a command line, and enter this command:
Wmic /output:services.htm /node:localhost service list brief /format:htableThis creates an HTML-formatted file named services.htm. You can view it by entering services.htm at the command prompt, which will launch Internet Explorer displaying the document. This lists all of the services on the system, as well as the start mode, the state, the status, and some additional details.
Now, use the same command to document the services of a remote computer that has been configured with WinRS. Substitute Srv2012 for the name of the server you have configured with WinRS, and change the name of the HTML file:
WinRS -r:Srv2012 Wmic /output:Srv2012services.htm /node:Srv2012 service list brief /format:htableYou can view this file by entering the name of the file at the command prompt. In this example, it is Srv2012services.htm.
If you want more details on the services, change list brief to list full. This simple tool can easily give you some important documentation on multiple servers that you can easily print or save.
Although WMIC is certainly feature rich, it’s not the only command you can use. Any command that you can enter at the server you can also enter remotely using WinRS. This includes PowerShell commands. The following link shows the PowerShell cmdlets:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee309371(v=vs.85).aspx
PowerShell commands follow a verb-noun format. The verb specifies an action, and the noun identifies the object on which the action will take place.
The most popular verb is get, and if you enter get- at the PowerShell command prompt, you can tab through all the nouns associated with the get verb.
Other verbs include set, copy, move, and many more. You can do the same thing with any of the verbs; enter the verb with a hyphen (-), and tab through all the possible nouns associated with the verb. For a full list of the verbs, check out this MSDN page: http://msdn.microsoft.com/en-us/library/ms714428(VS.85).aspx.
For example, you can enter the following PowerShell command from the PowerShell prompt to check the status of services on a system:
Get-ServiceYou don’t even need to type in the entire command. You can just type Get-S and press the Tab key.
This command will list all the services on the system with the status (running or stopped), name, and display name. Using this with WinRS, you can execute the same command remotely:
WinRS -r:SRV2012 PowerShell Get-ServiceIf you want to redirect this to a file, you can add the > redirect character as follows:
WinRS -r:SRV2012 PowerShell Get-Service > services.txtThe output will be stored in a file named services.txt. You can then open the file with Notepad from the command line with this command:
Notepad services.txtThe Remote Server Administration Tools (RSAT) are tools you need to manage roles and features on a Windows Server 2012 R2 server from your desktop operating system.
Although Remote Desktop Connection and Remote Desktops allow you to connect to the desktop of a server, sometimes you simply need to do a single task such as resetting a password on a user account or verifying that DNS is configured correctly.
RSAT includes tools like Active Directory Users and Computers (ADUC) and the DNS console. After installing RSAT on a desktop, you can launch ADUC to manipulate user accounts, or you can launch the DNS console to verify DNS configuration.
Users still need the appropriate permissions to run the installed tools. For example, a junior administrator who installs the tools on their desktop system won’t be added to the Enterprise Admins role and suddenly be able to perform anything in the forest.
The tools available in RSAT can be used to Manage Windows Server 2012 R2 roles and features.
RSAT is not compatible with the Administration Tools Pack used to remotely administer Windows Server 2000 and Windows Server 2003 servers. If you have these tools installed on your system, you must first uninstall them before installing RSAT.
Additionally, RSAT won’t allow you to remotely manage a server with the Streaming Media Services role. There are separate Remote Server Administration Tools for the Streaming Media Services role you can download and install to manage a Windows Server 2012 R2 server hosting the Streaming Media Services role.
For more information on issues with a Streaming Media Services role server, check out the Microsoft KB article at http://support.microsoft.com/kb/934518. The RSAT information is located near the end of the article.
After installing RSAT on a desktop system, you’ll have access to a full suite of tools that you’d find on a Windows Server 2012 R2 server with all of the roles and features installed. As long as the remote server has the appropriate role or feature installed, you can use the client-side RSAT tool to administer it.
In other words, if a server is running the DHCP role, you can use the DHCP console to remotely administer it. However, if the server isn’t a DHCP server, you can’t use the RSAT-installed DHCP console to make it a DHCP server.
The following list shows some of the more commonly used tools available with RSAT. This isn’t meant to be an exhaustive list but instead a summary of some of the commonly used tools. For a complete list, check out the Microsoft KB article at http://support.microsoft.com/kb/941317.
RSAT is available as a free download from Microsoft. You can download RSAT by going to the Microsoft download site at www.Microsoft.com/downloads and typing RSAT.
Once you’ve downloaded RSAT, you can follow these steps to install and enable RSAT:
Control Panel to launch Control Panel.Figure 17.40 Adding the Remote Server Administration Tools feature
If Administrative Tools does not show on your Start menu, you can add the tools by following these steps:
Once RSAT is installed on a system, you can use the tools in the same way you would use them on a server.
Before we close out this chapter, let’s discuss how you can use PowerShell to remotely connect to another PowerShell session. If you do not plan on using PowerShell to remotely administer your server, then you can skip this section. If you plan on using PowerShell, then stick around and see how you can connect remotely using PowerShell cmdlets.
When you are sending cmdlets to the server, you will need to provide a username and password just like in the Remote Desktop UI. If you have to type several commands, you will have to enter this username and password for each command. To get around this you can assign the username and password to a session variable that will be hold the credentials for you.
When you enter the following command, you will see a login pop-up appear to enter your credentials (see Figure 17.41).
Figure 17.41 Login credential pop-up screen
$cr = Get-Credential -Credential jpwebconsulting\administratorNow all your login information is stored in the $cr variable. You will see in the next cmdlet how this will be of use to you. The next cmdlet you will use is your connection to the remote system. You can now see the variable in use:
Enter-PSSession -ComputerName TestServer-1 -Credential $crYou are now connected remotely to the server via PowerShell. You should see the following command prompt, and you will see that it switched over to TestServer-1. You can now administer the server as if you were sitting in front of it. I bet you didn’t think it was that easy!
[TestServer-1]: PS C:\Users\Administrator\Documents>