How to setup Remote Administration Tools of Windows 10 and Windows 11?

Once your environment reaches more than ten computers, the ability to centrally manage them becomes critical to prevent the need to carry out manual administrative tasks on each one or to have to physically visit the machine when something goes wrong. Automating changes to hundreds or thousands of computers with a standard configuration and ensuring it is done safely is a key skill of any enterprise administrator.
The Microsoft Remote Server Administration Tools (RSAT) is an essential tool set when we think of physically remote or non-UI servers.
These are common in enterprise environments with data centers. The further extension of the server nano and core versions makes tools that can remotely manage systems even more important to understand. In addition to the RSAT provided by Microsoft as a GUI to perform tasks, PowerShell is increasingly the preferred and advised method of remote administration for both servers and clients. This is extended further as enterprise environments have hybrid cloud environments that include capabilities such as Azure Active Directory (Azure AD) and Azure RemoteApp. Other tools are also available to ensure you can achieve the maximum level of automation and remote administration to support your environment.
In this Article, we'll learn the following:

• How to install and configure RSAT
• How to perform administrative tasks using the RSAT tool
• How to configure the enterprise for secure PowerShell remoting
• How to perform remote administration using PowerShell
• A brief introduction to Desired State Configuration (DSC)
• The system internals suite of tools, including BgInfo and PsTools

Remote Server Administration Tools

Since Windows Server 2008 R2, these tools are installed on all servers by default, and can be installed on the administrator's workstation to carry out remote administration, preventing the need to use Remote Desktop Protocol (RDP) to log onto each server. The tools enable remote management of roles and features across one or multiple remote servers.
The following sections will show you how to install the tools and get started using them to administer your servers.

Installing RSAT

Installing RSAT on a workstation involves downloading a package that includes some Windows PowerShell cmdlets and providers, command-line tools, and the MMC snap-ins needed to present the GUIs. The location doesn't appear to have changed for this tool in over a year and is at https://www.microsoft.com/en-us/download/details.aspx?id=45520. The file names still (at the time of writing) display the WindowsTH monicker (from threshold most likely), but work on the Enterprise, Professional, or Education Windows 10 editions. There are two files available to download, the WS2016-x86 and WS2016-x64 versions. Install the one for your OS's bitness.
There are a few caveats to applying RSAT:

• You must remove older versions before applying a new one. Only one instance can be present on a machine at a time
• You must update your older servers to be able to use the Windows 10 RSAT tools to connect to them (see http://go.microsoft.com/fwlink/?LinkID=241358 for details)
• After updating your Windows version from one major build to another, you may need to reinstall the RSAT tools again
• After downloading and installing the RSAT binary, you must enable it in the Turn Windows features on or off area of Windows

If you wish to have a system with less than the full set of RSAT tools available, you can open Turn Windows features on or off, browse to Windows Features\Remote Server Administration Tools\, expand either Role Administration Tools\ or Feature Administration Tools\, and then uncheck the boxes of any tools you wish to disable.

Do note that if you disable Server Manager, you have to access the other tools from the Start menu or search, as Server Manager won't be there to bind them together.

RSAT usage

Server Manager, for those who are not familiar, lets you quickly configure multiple servers, so it does have some risks as well as great capability. By default, Server Manager will not see any servers in the environment; it is up to the administrator to add them manually. Simply click on All Servers and then right-click to be prompted to Add Servers.

Once you do so, you are rewarded with a window to allow you to import a configuration file, perform a DNS query, or even search Active Directory. Filters are available to only find particular versions of Windows Server, and you can filter by name or partial name as well:

Note the results: two hosts in my Active Directory. One is a Windows 10 Enterprise system, and the other a Windows Server 2012 R2 Standard server. Simply select the result or results you want and add them to the right by clicking on the button in the middle. Then click on OK.
The Server Manager detects that I have added a domain controller and gives me the options available on that server natively (AD DS (a.k.a Active Directory Domain Services), DNS (a.k.a Domain Name Services), File and Storage Services, and VA (a.k.a Volume Activation Services)). To access one of these services, simply select it, and then in the Servers pane, right-click and select the option desired.

This workflow is fine if you are logged in as the account that has administrative rights already. However, that is typically not the case in an enterprise environment. Usually, the least privileges are enforced and your typical account on your machine does not have the rights to connect to a domain controller and start monkeying with it. In this scenario, the workflow is a little different. You can still execute the Server Manager, but you'll be prompted that your credentials are insufficient soon enough. When the domain controller is added (as in the previous example), once you click on OK, you are rewarded with a red flag. Clicking on it reveals the problem:

To work around this, do the following:
Right-click on the server as you did before to manage it, but select Manage As... and provide your credentials when prompted to run the connection to this host as an alternative account with the appropriate rights. Check the box to remember the credentials for later use (not recommended in secure environments):

The appropriate server capabilities will then populate, as the appropriate account can query the server to understand what is needed to manage it remotely:

Removing a server is as simple as returning to All Servers and right-clicking on Remove Server. Note the filter area above the server list. You can search for only certain server group names in this method to perform actions en masse. You can also save filtered queries for later using the buttons next to the filter box.
All the UIs for these RSAT tools follow the familiar Microsoft Management Console (MMC) format. There will be action options on the right, the objects listed on the left, and further details in the middle pane. The only real complication with running these in an environment is either account rights or connectivity. In most of the RSAT contexts, you can simply supply alternate credentials in the tool UI.
For example, if you needed to check on the Dynamic Host Configuration Protocol (DHCP) scope or reservations in your environment, you could simply open DHCP from the RSAT tools. Note when it is opened that it does not pre-populate any servers in your environment. No discovery is going on here across the network, yet:

To add the correct DHCP host or hosts, simply right-click on DHCP on the left. Note that you are presented with two choices, Add Server and Manage Authorized Servers. The easy option is Manage Authorized Servers. In Windows, an Authorized DHCP server is one that is allowed to dispense IP addresses on your network, among other things. Click on Manage Authorized Servers and then click on the Refresh button:

What happened when you clicked on the Refresh button was that an Lightweight Directory Access Protocol (LDAP) query was executed on the domain, and the list of authorized servers returned. In this domain, there is only one authorized server, dc-01.illuminati.services.
So select the server and click on the OK button. Now you are able to administer the DHCP scope, policies, filters, static address assignments, and so on:

But what if you needed to add the server manually? Instead of the authorized option, you'd simply add a server by selecting Add Server, and then you can Browse your AD for the appropriate host:

Now we need to know the hostname, the OU the server is located in, or some other metadata to locate the host running DHCP.
Note that if you intend to use these tools to manage versions of Windows Server older than 2016, you'll want to apply hotfixes to the older servers so the RSAT tools work properly.

PowerShell

Microsoft PowerShell is the preferred way to perform many enterprise administrative tasks. The flexibility to quickly perform tasks on OUs of computers in AD, or query a network subnet of Windows machines, or even remotely query which host is locking out a user account are all things that PowerShell shines at enabling an administrator to perform at a moment's notice.
PowerShell has become robust enough that it is not unheard of for OEMs and partners to also create their own cmdlets that can be imported into your scripting environment and used. Script sharing is possible: the Microsoft TechNet Hey Scripting Guy! library is an excellent resource for accessing trusted and peer-reviewed PowerShell scripts to perform a variety of tasks. VMWare is one company that has created their own PowerShell scripts.
The ability to automate common administrative tasks in a scripted method means that the enterprise administrator can focus on making good decisions for their environment, as opposed to working quickly in ancient UIs, where repetitive tasks on large groups of computers or users often led to mistakes, typos, and subsequent outages as a result.
Microsoft Azure has further extended PowerShell with a large array of PowerShell cmdlets and sample scripts to administer Azure-based services, such as Azure AD and Azure RemoteApp.
Generally speaking, PowerShell follows a hierarchy of verb/noun: GetObject, Get-Help, ConvertTo-HTML, and so on. These commands all create output that in turn can be an object for another script. Chaining together PowerShell cmdlets into scripted actions is the heart of how the language works.

PowerShell setup

Microsoft PowerShell comes configured by default on Windows machines to not run unsigned scripts. These are scripts or tidbits from unknown sources that are not digitally signed. Microsoft PowerShell is configured on hosts by default to only run signed scripts.
The typical admin in need of a quick fix will use Set-ExecutionPolicy to set the policy on the local machine to Unrestricted and then perform the administrative task. Sometimes they will remember to set it back to AllSigned as well; sometimes they forget and leave a security hole on the system that can later be exploited for malicious intent.
It is far better to sign your scripts used in the enterprise in a proper manner using a private key infrastructure in your domain. This is accomplished using a PowerShell cmdlet, naturally. The cmdlet is Set-AuthenticodeSignature, which can be used to generate certificates that can then be trusted by the organization in a Group Policy or Local Policy, as the case may be. A thorough post on the subject written by Ed Wilson (the Scripting Guy on TechNet) is located at http://bit.ly/pkimyscripts.
I highly recommend and advise that some sort of testing and vetting process be followed for your scripting environment and library in production. Part of that process should be a signing/trust mechanism for the scripts.
PowerShell, if left wide open, can be abused quite a bit to impact production systems in negative ways or be used as an attack vector for further activities by custom malware.

PowerShell usage

Conceptually, PowerShell is a command-line shell scripting language. It is built on the .NET Framework and .NET Core. It is open source and cross platform as well. On Windows systems, it is a great way to perform administrative tasks using WMI, AD locations, or even input as part of script execution.
Generally speaking, the workflow of a PowerShell execution is where a cmdlet is called, with or without multiple defined variables given in the command. The output can be formatted in a variety of predefined ways and is also an object to be leveraged in a script as input for your next cmdlet or script step.
For example, one could run get-disk 0 to determine what our OS sees as the disk defined as 0:

But that is great input for an even more enlightening command to determine whether it is working properly.
This is easy to do with get-disk 0 | Get-StorageReliabilityCounter.
This command takes our results from get-disk 0 and pipes them into GetStorageReliabilityCounter to see some of the smart data from the drive:

Now we can see that this drive is in decent shape despite 14,000 hours of on time.
What if we wanted this for a report though? Or wanted it for multiple computers or multiple drives?
The get-help Get-StorageReliabilityCounter command reveals that there isn't a built-in output to say, HTML format. But if we use get-help html, we can find a cmdlet that does it for us!

So now we take our commands and chain them together. I picked -as table as well, so it is nice and neat.
Note that the output is not as I may have intended:

The reason for this is the environment sends its output to the console by default. I never told the commands otherwise.
Let's add an out-file command. Now our command prompt should look like this:
get-disk 0,1 | Get-StorageReliabilityCounter | convertto-html | out-file report.html And we get this result:

We retrieved all information from Get-StorageReliabilityCounter though, so the report is pretty wide. What if we didn't need all that?
Filter it; something like this should work:
get-disk 0,1 | Get-StorageReliabilityCounter | Select-Object PowerOnHours, ReadErrorsUncorrected | convertto-html | out-file report.html
Now we open our HTML report and see results for disk 0 and 1.

Now all this is well and good, but how do we collect information for a series of machines? Or even just a single remote machine?

PowerShell in the Enterprise

Let's say you need to know which Windows machines are in an Organizational Unit (OU) in AD:
Get-ADComputer -filter 'OperatingSystem -NotLike "*server*"' -SearchBase "CN=<OU name>,DC=Illuminati,DC=Services" | Select-Object -expand Name
If we wanted that in a file for, say, Excel consumption, just add an export command:
Get-ADComputer -filter 'OperatingSystem -NotLike "*server*"' -SearchBase "CN=<OU name>,DC=Illuminati,DC=Services" | Select-Object -expand Name | Export-CSV AllWindows.csv
But what if we need to do something other than query? Let's take the previous example. We are getting a list of all computers in a specific OU in AD. Great!
Let's find out if their hard drives are healthy. With solid state drives, once the disk controller goes bad, you tend to just lose everything on the drive. Generally, in an enterprise environment, this isn't a big deal, because you are backing up user data using roaming profiles, UE-V, OneDrive for Business, or something else; something other than letting users just store important business documents on a single non-highly available host.
So let's build a script that does this using the one we just wrote as a framework:
Get-ADComputer -filter 'OperatingSystem -NotLike "*server*"' -SearchBase "CN=Computers,DC=Illuminati,DC=Services" | Get-PhysicalDisk | Select-Object FriendlyName, HealthyStatus | Export-CSV results.csv
This returns a CSV of our machines and their disk health.
Another nice feature for PowerShell, if you want to get information from just a single machine instead of the domain at large, are the following commands that can be used without any preconfiguration of your environment:

• Get-WinEvent
• Get-Counter
• Get-EventLog
• Clear-EventLog
• Write-EventLog
• Limit-EventLog
• Show-EventLog
• New-EventLog
• Remove-EventLog
• Get-WmiObject
• Get-Process
• Get-Service
• Set-Service
• Get-HotFix
• Restart-Computer
• Stop-Computer
• Add-Computer
• Remove-Computer
• Rename-Computer
• Reset-ComputerMachinePassword

If you had something that needed more control over a computer in your environment, then you would need to look into what used to be called Windows Remote Management (WinRM) but is now the foundation used by PowerShell for PowerShell remoting. This is pretty easy to do and is best done via Group Policy.
The GPO you want to set is in the Computer Configuration area of Group Policy. You'll find it here: Policies/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service The specific policy to set to Enabled is this: Allow Remote Server management through WinRM You may also want to set this to automatically work by changing the service to start automatically: Policies/Windows Settings/Security Settings/System Services
Set the service to Automatic: Windows Remote Management (WSManagement)
You'll also want to manage the domain policy in Windows Firewall to allow the Windows Remote Management traffic predefined firewall rule: Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Windows Firewall with Advanced Security/Inbound Rules Set that rule to Allowed.
When we consider tasks in the enterprise environment and how remote administration in PowerShell can help, it helps to break them into scenarios: perform some sort of action on a system or object, or get data from a computer or object (such as directory services).

Desired State Configuration

Desired State Configuration (DSC) is a management framework in PowerShell that can provide a standardized way of defining how a system should be configured. This enables the complete automation of device configuration using a declarative model: you create a configuration that states how a device should be configured, publish that configuration, then wait for the devices to update themselves to match the configuration.
A single configuration can be used across multiple devices, ensuring they are maintained with identical and standardized settings. This prevents configuration drift when multiple changes occur over a period of time.
DSC supports two deployment methods:

• Push mode: In this mode, the administrator makes the configurations and then manually pushes them out to the target devices. This is a oneway communication, and can only work if the devices are available on the network at the time of the push. It also assumes the appropriate PowerShell modules are available on all devices. This option is best suited to small environments where all devices are connected at all times.
• Pull mode: In this mode, the administrator creates a pull server that is used to host the configurations. Then, each of the devices is configured to contact this server at regular intervals (such as every 15 minutes) to look for any changes to configurations. If found, the device can pull both the DSC data as well as any required modules. This automates the deployment of configurations to a high frequency and doesn't require further interaction from the administrator.

DSC has both a configuration and a resource side, and a configuration manager runs the show between the two:

• Configurations: These are PowerShell scripts that define and configure the resources. The DSC engine will look at the configuration and resources available and make the system adopt the desired state.
• Resources: A resource is code that keeps the target of a configuration in a specific state. These are in PowerShell modules most typically. By default, DSC has several resources, which you can see by running the get-dscresource cmdlet:

• Local Configuration Manager (LCM): This runs on the local device to ensure that the configuration is applied correctly. The LCM polls the system to ensure the state defined by the configuration is maintained and corrects any errors.

An example of how you would use DSC configurations would be to prevent a specific process from running, or having a registry key or security policy set in a specific way to meet your security requirements. Think of this capability as Group Policy, but augmenting it with much greater flexibility.

Windows Sysinternals tools suite

Microsoft provides a range of advanced administration tools, known as the Sysinternals suite. You can explore the tools by viewing the TechNet site: https://technet.microsoft.com/en-us/sysinternals.
From here you can gain access to the tools with reference information on how to use them, get updates on changes as they are published, watch instruction videos, and discuss the tools in the forum.
The following sections will explore BgInfo, for displaying useful information on a user's desktop, and the PsTools suite of remote control tools.

BgInfo

A very useful tool available from the Systinternals Suite of tools is BgInfo. This tool enables specific system information to be available when the user logs in by displaying it as text on the background or in a popup box in the system tray. This can be very handy when they need to call the helpdesk to report an issue and provide detailed information to help with troubleshooting. The tools can be deployed to all computers and applied to the logon screen and users' desktop wallpaper--even if the user has a custom background on their desktop that changes frequently, BgInfo can overlay the text on top of the custom image and update frequently.
This section will explain how to configure the options you want to display and then deploy the tool and custom configuration to all your computers to ensure the information is displayed the same way for everyone.

Configuring BGInfo

Launch the BgInfo tool on your local computer, or one that represents the configuration of your intended targets. Configure the options you want, and then save the custom BgInfo configuration file using File | Save settings.
The following options are available to configure what information is to be displayed, and how it appears:
Buttons:

• Fields: Select what information should be collected and displayed. You can choose from the list of standard options or create your own custom fields, as you can see in this screen:

• Background: Choose a solid color or a wallpaper to use for the background. You can also choose to copy the existing settings, which will allow the user to select their own backgrounds while still displaying BgInfo information.
• Position: You can choose from nine possible screen positions and options to cater for multiple screens.
• Desktops: Choose which types of desktop are updated by BgInfo: the logon screen, local user desktop, and Remote Desktop logon.
• Preview: If you select this button while you are configuring the options, you can see the image in the background as you create and change the options. This information is dynamically updated to ensure it accurately reflects your configuration options.

Top menu:

• File: This menu allows you to save various copies of the files and restore them to default settings. You can also specify a database or text file that can be used to store information that is retrieved by BgInfo, which can be very useful if you are trying to carry out an audit or check for configuration changes that are occurring.
• Bitmap: The output of the BgInfo file is a bitmap image; this menu option allows configuring the size and quality of the image.
• Edit: This menu allows you to insert an image, such as your company logo.
• Format: There are a wide range of options to modify the size, style, and color of the text to suit your preference.

You should now have a customized .bgi file you can use to configure other computers. The next step will show you how to deploy this to all your computers.

Deployment

To deploy the solution, you need to find the most suitable way of transferring both the BgInfo executable (.exe) and the BgInfo configuration file (.bgi) to the remote computers as well as configuring the appropriate script to run at logon/startup. The simplest method is to create a share on a central server that all clients can reach and then uploading the two files (.exe and .bgi). The next step is to create a script and run it on each computer: in an AD environment, create a logon script and deploy it using Group Policy to target the computers.
The following scripting options are available to modify the behavior of BgInfo when it runs:
<path>: Specifies the name of a configuration file to use for the current session. It is recommended you save this to a read-only share to ensure other users do not modify the settings.
/timer: Specifies the timeout value for the countdown timer, in seconds. Specifying zero will update the display without displaying the configuration dialog. Specifying 300 seconds or longer disables the timer altogether.
/popup: Causes BgInfo to create a popup window containing the configured information without updating the desktop. The information is formatted exactly as it would if displayed on the desktop, but resides in a fitted window instead. When using this option, the history database is not updated.
/silent: This option suppresses any error messages; remove it when troubleshooting any issues.
/taskbar: Causes BgInfo to place an icon in the taskbar's status area without updating the desktop. Clicking on the icon causes the configured information to appear in a popup window. When using this option, the history database is not updated.
/all: Specifies that BgInfo should change the wallpaper for any and all users currently logged in to the system. This option is useful within a Terminal Services environment, or when BgInfo is scheduled to run periodically on a system used by more than one person.
/log: BgInfo will write errors to the specified log file instead of generating a warning dialog box. This is useful for tracking down errors that occur when BgInfo is run under the scheduler.
/rtf: BgInfo will write its output text to an RTF file. All formatting information and colors are included.
So the resulting command may look something like this:
reg add HKU\.DEFAULT\Software\Sysinternals\BGInfo /v EulaAccepted /t REG_DWORD /d
1 /f
\\Server\Share\Bginfo.exe \\Server\Share\template.bgi /TIMER:00 /nolicprompt

Introducing PsTools

The Sysinternals Suite of remote-control tools bears mention in this Article as well. The PsTools binaries provide a method for remote system administration using the command-line. While PowerShell fills the need for powerful command-line remoting capabilities in Windows 10, earlier editions come with older versions of PowerShell by default or don't even come with it at all.
Installation is as simple as downloading the PsTools suite from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx and extracting the ZIP file.
Execute them in an elevated Command Prompt. Setting them as part of your system path can be handy but also an easy attack vector, so carefully considers the impact before configuring.
The tools themselves are executable command-line binaries that perform different system tasks; many of them can be used on remote systems with ease. The ZIP contains the following binaries:

• PsExec: Execute processes on remote hosts
• PsFile: Show files opened remotely
• PsGetSid: Display the SID of a computer or user object
• PsInfo: List information about a host
• PsPing: Measure network performance
• PsKill: Kill processes by either name or PID
• PsList: List detailed information about processes on a host
• PsLoggedOn: See who's logged on locally and also via sharing
• PsLogList: Dump event logs
• PsPasswd: Change account passwords
• PsService: View and control services
• PsShutdown: Shut down and optionally reboot a host
• PsSuspend: Suspend processes

As you can see, these are some powerful tools that enhance the tool belt of the enterprise administrator. Because of this, some network and security administrators will want to block these tools to prevent abuse and attack vectors. This is difficult to do as the ports used are TCP ports 135 and 445.
These may sound familiar: port 135 is designated for DCOMSCM and port 445 is designated for Microsoft Directory Services. Specifically, this port is used for Server Message Block (SMB) file sharing and other administrative concepts in Windows.
As a result, these need to be open and running. File sharing (IPC specifically) needs to be available. The remote registry service needs to be turned on for some actions as well.
If you do try to block this, you'd in essence be blocking file sharing and inter-node communication of Windows machines. It is worth noting that you need knowledge of administrator-level accounts to use PsTools. So it is more important to practice good account security and auditing than it is to worry about this tool, assuming everything else is the same.

Installing PsTools

PsTools uses a familiar syntax if you are already used to using a commandline in Windows. Simply open an elevated Command Prompt in the directory where PsTools was unzipped.
Using your elevated Command Prompt, type psexec and hit enter. You should be prompted for the EULA of the Sysinternals Suite of software:

To avoid hitting the Sysinternals EULA notice on every system you use it on, use the -accepteula switch. This is true of Process Explorer, Process Monitor, and most of the Sysinternals tools. This can be very important when we want to script out a solution or run procmon on a remote machine. Check out this command:
C:\PSTools>psexec \\win81 -u ILLUMINATI\demo -u P@ssword1 -c -f procmon
It gives you this:

And it ends with:
This is the first run of this program. You must accept EULA to continue.
Use -accepteula to accept EULA.
procmon.exe exited on win81 with error code 1.
So a simple addition of the switch will give you better results (note that the - c is to copy the binary locally and -f is to specify the file, which was in the same directory as my Command Prompt).
Sometimes it is necessary to chain commands. For example, psinfo requires the remote registry service to be enabled. In Windows 8.1, it ships as a disabled service. So if we wanted to use PsInfo host win81 we'd need something like this:
C:\pstools\psservice \\win81 setconfig remoteregistry auto && C:\pstools\psinfo
\\win81
PsInfo v1.78 - Local and remote system information viewer
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
System information for \\win81:
Uptime: 0 days 0 hours 56 minutes 15 seconds
Kernel version: Windows 8.1 Enterprise, Multiprocessor Free
Product type: Professional
Product version: 6.3
Service pack: 0
Kernel build number: 9600
Registered organization:
Registered owner: fred
IE version: 9.0000
System root: C:\Windows
Processors: 4

Using PsTools

As there are many tools to choose from, let's explore some of the most useful ones to understand where you can get started:
psexec: This lets you remotely execute a process on a single or multiple computers. The input and output of any console applications are redirected so they appear to be running locally. This is usually used to run a Command Prompt on a remote computer, then enter commands like ipconfig /all and see the output from that remote computer, which prevents the need to go the long-winded way of using remote desktop, logging on, launching the Command Prompt, and then finding a way of extracting the output. This option can also be used to ensure any application that is launched can run in the background, so when a user or administrator logs off, the program can continue to run.
The basic syntax to use looks like this:
psexec \\computername [options] program [arguments]
To run ipconfig on a remote computer, you can run the following command:
psexec \\client1 ipconfig /all
If you need to use alternative credentials, you can run this command:
psexec \\client1 ipconfig /all -u "domain\userid" -p password
There are many switches available with this tool, and it is a good idea to spend some time reviewing them in the help guides to fully understand the potential uses.
psfile: The main purpose of this tool is to query a computer to list the files that are currently open on remote systems. To see files opened on a remote system, use the following syntax:
psfile \\computername C:\filepath
If you need to gain access to a file that is currently locked by a process, you can close the file using the -c command, but this should be done with caution as any unwritten data may be lost.
psgetsid: Windows Security Identifiers (SIDs) allow unique identities for computer, groups, users, and other system objects. While the visible name of an object may change, the SID always remains unique for the life of the object. Each computer has a machine SID, which is created during the setup process. If the computer is joined to an AD domain, then it has a relative ID (RID) applied also, to create a unique SID in the domain. This way, you can query information based on a very specific identity without relying on names that may be changed or duplicated.
The PsGetSid tool provides a simple way of translating from the name to an SID or vice versa. Use the following command syntax to display the SID of a given account name:
psgetsid accountname
psinfo: This tool gathers key information about a system to understand details such as the operating system, product version, number and type of processors, physical memory, and video driver. This information can be useful to check the compatibility of a system before installing software upgrades or to query all computers and find those that don't meet your minimum requirements or those that have a specific application or hot-fix installed.
psinfo \\computername
To gather further information and control how the reports are generated, you can use the following commands:
-c to send the results to a CSV file
-d to gather disk information
-h to show all installed hot-fixes
-s to list all software applications installed
-t use this to specify a different delimiter character
pslist: When you need to carry out a detailed inspection of a remote computer, it is useful to understand what processes are currently running on the system. The most important consideration for this tool is the use of the command-line arguments that allow you to query for specific information instead of seeing every process.
By default, this tool displays only CPU information. The following commands allow you to show additional details about one or more processes. Due to the details included, you may want to run these against specific processes or export it to a CSV file to compare all processes:
-d to display details about the threads for each process
-m to display the memory information about each process
-x to display CPU, thread, and memory information about each process
These commands can be combined to show detailed information about processes. The following example shows PsList being used to list all details about a specific application on a remote computer:
pslist \\computername -x -e appname
You can also use the -t command to show the processes in a tree view, to show the parent/child relationship (this cannot be used with the -d, -m, and -x commands).
pskill: Once you have used PsList to identify processes running on a system, you can use pskill to terminate the process. This can be specified either by the name or PID of the specific process, or the whole process tree (parent process and all child processes). This is a powerful tool that will terminate the process immediately, which means it will not have the opportunity to shut down cleanly, which could result in data loss or system instability if used inappropriately. The following command will connect to the machine specified and kill the PID listed:
pskill \\computername PID
To terminate the process tree, specify the -t switch.
psservice: With this tool, you can remotely view and control services and drivers. The basic controls include the ability to start, stop, restart, and pause a service. You can query services and drivers for specific information such as dependent services, security configurations, and load order (on boot). You can also configure a service or driver to change details such as the account name under which the service runs, or change the load order so it occurs earlier or later upon next boot.
A unique ability of this service is the search function. Using the find command, you can search your network for all instances of a service. For example, to find all computers running the DNS server service, use the following command:
psservice find "dns server" all
psloggedon: Another useful thing when investigating client computer activity is to understand whether whoever has connected to the computer has as a direct log on or remote sharing. To show a list of all users logged on to a specific computer, use this command:
psloggedon \\computername
Alternatively, you can use this tool to search all computers in the domain or local workgroup, but be aware that this may take some time to complete depending on the number of computers and the size of the network. To do this, specify a username instead of the computer name:
psloggedon username

Custom code repository

With all these tools and flexibility at the hands of an administrator, or more likely team of administrators in an enterprise environment, there exists a great risk of duplication of effort as each administrator just sees a problem and whips up a PowerShell solution, for example. Having a GitHub repository of scripts and tools certainly makes sense so that you can maintain versioning of frequently used scripts as they are iterated on and improved. Also, you need to make sure that everyone is in sync with how administration using automated scripts should be done. The problem you are solving with a repository is the John wrote a script and now none of the machines boot issue. This is a bad place to be; generally, these are resumegenerating events.

Summary

To summarize this chapter, we've learned of a few different options to remotely manage your enterprise environment. The key to learning automation and administration is to do, but do carefully. We cannot overstate the risk of a badly written script executing in an environment with domain administration credentials.