This command configures the computer to receive remote commands.
The Enable-PSRemoting cmdlet configures the computer to receive Windows PowerShell remote commands that are sent.
to enable Windows PowerShell remoting on other supported versions of Windows
You need to run this command only once on each computer that will receive commands. You do not need to run it on computers that only send commands. Because the configuration activates listeners, it is prudent to run it only where it is needed.
To run this cmdlet, start Windows PowerShell with the “Run as administrator” option.
CAUTION: On systems that have both Windows PowerShell 3.0 and the Windows PowerShell 2.0 engine, do not use Windows PowerShell 2.0 to run the Enable-PSRemoting and Disable-PSRemoting cmdlets. The commands might appear to succeed, but the remoting is not configured correctly. Remote commands, and later attempts to enable and disable remoting, are likely to fail.
In Windows PowerShell 3.0, Enable-PSRemoting creates the following firewall exceptions for WS-Management communications.On server versions of Windows, Enable-PSRemoting creates firewall rules for private and domain networks that allow remote access, and creates a firewall rule for public networks that allows remote access only from computers in the same local subnet.On client versions of Windows, Enable-PSRemoting in Windows PowerShell 3.0 creates firewall rules for private and domain networks that allow unrestricted remote access. To create a firewall rule for public networks that allows remote access from the same local subnet, use the SkipNetworkProfileCheckparameter.On client or server versions of Windows, to create a firewall rule for public networks that removes the local subnet restriction and allows remote access , use the Set-NetFirewallRule cmdlet in the NetSecurity module to run the following command: Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
In Windows PowerShell 2.0, Enable-PSRemoting creates the following firewall exceptions for WS-Management communications.On server versions of Windows, it creates firewall rules for all networks that allow remote access.On client versions of Windows, Enable-PSRemoting in Windows PowerShell 2.0 creates a firewall exception only for domain and private network locations. To minimize security risks, Enable-PSRemoting does not create a firewall rule for public networks on client versions of Windows. When the current network location is public, Enable-PSRemoting returns the following message: “Unable to check the status of the firewall.”
Beginning in Windows PowerShell 3.0, Enable-PSRemoting enables all session configurations by setting the value of the Enabled property of all session configurations (WSMan:\<ComputerName>\Plugin\<SessionConfigurationName>\Enabled) to True ($true).
In Windows PowerShell 2.0, Enable-PSRemoting removes the Deny_All setting from the security descriptor of session configurations. In Windows PowerShell 3.0, Enable-PSRemoting removes the Deny_All and Network_Deny_All settings, thereby providing remote access to session configurations that were reserved for local use.
Enable-PSRemoting -Force
This command configures the computer to receive remote commands. It uses the Force parameter to suppress the user prompts.
Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
This example shows how to allow remote access from public networks on client versions of Windows. Before using these commands, analyze the security setting and verify that the computer network will be safe from harm.
The first command enables remoting in Windows PowerShell. By default, this creates network rules that allow remote access from private and domain networks. The command uses the SkipNetworkProfileCheckparameter to allow remote access from public networks in the same local subnet. The command uses the Force parameter to suppress confirmation messages.
The SkipNetworkProfileCheck parameter has no effect on server version of Windows, which allow remote access from public networks in the same local subnet by default.
The second command eliminates the subnet restriction. The command uses the Set-NetFirewallRule cmdlet in the NetSecurity module to add a firewall rule that allows remote access from public networks from any remote location, including locations in different subnets.
-SkipNetworkProfileCheck
Enables remoting on client versions of Windows when the computer is on a public network. This parameter enables a firewall rule for public networks that allows remote access only from computers in the same local subnet.
This parameter has no effect on server versions of Windows, which, by default, have a local subnet firewall rule for public networks. If the local subnet firewall rule is disabled on a server version of Windows, Enable-PSRemoting re-enables it, regardless of the value of this parameter.
To remove the local subnet restriction and enable remote access from all locations on public networks, use the Set-NetFirewallRule cmdlet in the NetSecurity module.
How to Run PowerShell Commands on Remote Computers
PowerShell Remoting lets you run PowerShell commands or access full PowerShell sessions on remote Windows systems. It’s similar to SSH for accessing remote terminals on other operating systems.
PowerShell is locked-down by default, so you’ll have to enable PowerShell Remoting before using it. This setup process is a bit more complex if you’re using a workgroup instead of a domain—for example, on a home network—but we’ll walk you through it.
Enable PowerShell Remoting on the PC You Want to Access Remotely
Your first step is to enable PowerShell Remoting on the PC to which you want to make remote connections. On that PC, you’ll need to open PowerShell with administrative privileges.
-In Windows 10, press Windows+X and then choose PowerShell (Admin) from the Power User menu.
-In Windows 7 or 8, hit Start, and then type “powershell.” Right-click the result and choose “Run as administrator.”
-In the PowerShell window, type the following cmdlet (PowerShell’s name for a command), and then hit Enter:
Enable-PSRemoting -Force
This command starts the WinRM service, sets it to start automatically with your system, and creates a firewall rule that allows incoming connections. The -Force part of the cmdlet tells PowerShell to perform these actions without prompting you for each step.
If your PCs are part of a domain, that’s all the setup you have to do. You can skip on ahead to testing your connection. If your computers are part of a workgroup—which they probably are on a home or small business network—you have a bit more setup work to do.
Note: Your success in setting up remoting in a domain environment depends entirely on your network’s setup. Remoting might be disabled—or even enabled—automatically by group policy configured by an admin. You might also not have the permissions you need to run PowerShell as an administrator. As always, check with your admins before you try anything like this. They might have good reasons for not allowing the practice, or they might be willing to set it up for you.
Set Up Your Workgroup
If your computers aren’t on a domain, you need to perform a few more steps to get things set up. You should have already enabled Remoting on the PC to which you want to connect, as we described in the previous section.
Note: For PowerShell Remoting to work in a workgroup environment, you must configure your network as a private, not public, network.
Next, you need to configure the TrustedHosts setting on both the PC to which you want to connect and the PC (or PCs) you want to connect from, so the computers will trust each other. You can do this in one of two ways.
If you’re on a home network where you want to go ahead and trust any PC to connect remotely, you can type the following cmdlet in PowerShell (again, you’ll need to run it as Administrator).
Set-Item wsman:\localhost\client\trustedhosts *
The asterisk is a wildcard symbol for all PCs. If instead you want to restrict computers that can connect, you can replace the asterisk with a comma-separated list of IP addresses or computer names for approved PCs.
After running that command, you’ll need to restart the WinRM service so your new settings take effect. Type the following cmdlet and then hit Enter:
Restart-Service WinRM
And remember, you’ll need to run those two cmdlets on the PC to which you want to connect, as well as on any PCs you want to connect from.
Test the Connection
Now that you’ve got your PCs set up for PowerShell Remoting, it’s time to test the connection. On the PC you want to access the remote system from, type the following cmdlet into PowerShell (replacing “COMPUTER” with the name or IP address of the remote PC), and then hit Enter:
Test-WsMan COMPUTER
This simple command tests whether the WinRM service is running on the remote PC. If it completes successfully, you’ll see information about the remote computer’s WinRM service in the window—signifying that WinRM is enabled and your PC can communicate. If the command fails, you’ll see an error message instead.
Execute a Single Remote Command
To run a command on the remote system, use the Invoke-Command cmdlet using the following syntax:
“COMPUTER” represents the remote PC’s name or IP address. “COMMAND” is the command you want to run. “USERNAME” is the username you want to run the command as on the remote computer. You’ll be prompted to enter a password for the username.
Here’s an example. I want to view the contents of the C:\ directory on a remote computer with the IP address 10.0.0.22. I want to use the username “wjgle,” so I would use the following command:
If you have several cmdlets you want to run on the remote PC, instead of repeatedly typing the Invoke-Command cmdlet and the remote IP address, you can start a remote session instead. Just type the following cmdlet and then hit Enter:
Enter-PSSession -ComputerName COMPUTER -Credential USER
Again, replace “COMPUTER” with the name or IP address of the remote PC and replace “USER” with the name of the user account you want to invoke.
Your prompt changes to indicate the remote computer to which you’re connected, and you can execute any number of PowerShell cmdlets directly on the remote system.
Enable-PSRemoting
Enable-PSRemoting configures a computer to receive PowerShell remote commands sent with WS-Management technology.
PS Remoting only needs to be enabled once on each computer that will receive commands.
Computers that only send commands do not need to have PS Remoting enabled; because the configuration activates listeners (and starts the WinRM service), it is prudent to run it only where needed.
The comma-separated list can be IP addresses or computer names or even a * wildcard to match all.
run : Restart-Service WinRM
To view the current trusted hosts: Get-Item WSMan:\localhost\Client\TrustedHosts
Examples
Configure the local computer to receive remote commands:
PS C:\> Enable-PSRemoting
Configure the computer to receive remote commands & suppress user prompts:
PS C:\> Enable-PSRemoting -Force
Configure the remote computer workstation64 to receive remote commands, via psexec. If you are running this from an account which is NOT a domain administrator, then specify the username/password of an account with admin rights to the remote machine:
Question: PowerShell: Configure WinRM and enable PSRemoting
1 – Enable WinRM
First thing to do before starting to manage your server remotely is to enable this function in your server. For this, you need to use the Windows Remote Management (WinRM) service. WinRM is the service which will allow you to use the WS-Management protocol necessary for the PowerShell remoting.
Enable WinRM is quite simple to do, you just need to run this command in a PowerShell prompt:
Winrm quickconfig or winrm qc
It should display a message like this if it is already configured:
Otherwise it will ask you to configure it:
2 – Enable PSRemoting
Once you have started your WinRM service, you must configure PowerShell itself to allow the remoting:
Enable-PSRemoting
3 – TrustedHosts file configuration
3.1 – Add server to the TrustedHosts file
The configuration above implies a domain environment. If you are working with servers which are not in your domain or in a trusted domain, you will have to add them in the TrustedHosts list of your local server. To do so, you must run the command below:
winrm s winrm/config/client ‘@{TrustedHosts=”MyServerName”}’
And the result you should see (you just need to replace “MyServerName” by the name of your server):
Another way to add a server to this file, by using the Set-Item cmdlet, like below:
In the command above you can see that I added two values between the quotes “ “. If you want to add more than one server to this file, you must add them separated by a coma. Attention anyway, if one day you decide to add a new server, if you run the same command with only one server name, it will overwrite the existing file. You need to add all the server names’ that must be in this file.
PowerShell will also prompt you to warn about the risks of adding a computer which is not trustworthy in this file.
And if I do a Get-Item, I should see my two servers:
Get-Item WSMan:\localhost\Client\TrustedHosts |fl
If you want to trust every servers which are not in your domain, even if it far far… far away from being secure… you can use the wildcard, like that:
Get-Item WSMan:\localhost\Client\TrustedHosts |fl Name, Value
And of course, sometimes it can also be interesting to be able to check this TrustedHosts file to see what is inside. You can also use PowerShell to it by using the Get-Item cmdlet:
Get-Item WSMan:\localhost\Client\TrustedHosts
3.2 – Remove servers from the TrustedHosts file
While you can easily add servers to your TrustedHosts file it can also be interesting to be able to remove a server from it, for security reasons, if you don’t need to use it anymore.
And by using this command, we can remove one server but still keeping the other servers in the list. As we can see on the output below:
Before clearing:
And after:
And there we are! Your PowerShell is now configured to handle the remote management.
Question: PowerShell Remoting Cheatsheet
I have become a big fan of PowerShell Remoting. I find my self using it for both penetration testing and standard management tasks. In this blog I’ll share a basic PowerShell Remoting cheatsheet so you can too.
Enabling PowerShell Remoting
Before we get started let’s make sure PowerShell Remoting is all setup on your system.
In a PowerShell console running as administrator enable PowerShell Remoting.Enable-PSRemoting –forceThis should be enough, but if you have to troubleshoot you can use the commands below
Make sure the WinRM service is setup to start automatically.# Set start mode to automatic
Set-Service WinRM -StartMode Automatic
# Verify start mode and state - it should be running
Get-WmiObject -Class win32_service | Where-Object {$_.name -like "WinRM"}
Set all remote hosts to trusted. Note: You may want to unset this later.
# Trust all hosts
Set-Item WSMan:localhost\client\trustedhosts -value *
# Verify trusted hosts configuration
Get-Item WSMan:\localhost\Client\TrustedHosts
Executing Remote Commands with PowerShell Remoting
Executing a Single Command on a Remote SystemThe “Invoke-Command” command can be used to run commands on remote systems. It can run as the current user or using alternative credentials from a non domain system. Examples below.Invoke-Command –ComputerName MyServer1 -ScriptBlock {Hostname}
Invoke-Command –ComputerName MyServer1 -Credential demo\serveradmin -ScriptBlock {Hostname}
If the ActiveDirectory PowerShell module is installed it’s possible to execute commands on many systems very quickly using the pipeline. Below is a basic example.Get-ADComputer -Filter * -properties name | select @{Name="computername";Expression={$_."name"}} | Invoke-Command -ScriptBlock {hostname}
Sometimes it’s nice to run scripts stored locally on your system against remote systems. Below are a few basic examples.Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 -Credential demo\serveradmin
Also, if your dynamically generating commands or functions being passed to remote systems you can use invoke-expression through invoke-command as shown below.$MyCommand = "hostname"
$MyFunction = "function evil {write-host `"Getting evil...`";iex -command $MyCommand};evil"
invoke-command -ComputerName MyServer1 -Credential demo\serveradmin -ScriptBlock {Invoke-Expression -Command "$args"} -ArgumentList $MyFunction
Establishing an Interactive PowerShell Console on a Remote SystemAn interactive PowerShell console can be obtained on a remote system using the “Enter-PsSession” command. It feels a little like SSH. Similar to “Invoke-Command”, “Enter-PsSession” can be run as the current user or using alternative credentials from a non domain system. Examples below.Enter-PsSession –ComputerName server1.domain.com
Enter-PsSession –ComputerName server1.domain.com –Credentials domain\serveradmin
If you want out of the PowerShell session the “Exit-PsSession” command can be used.Exit-PsSession
Creating Background SessionsThere is another cool feature of PowerShell Remoting that allows users to create background sessions using the “New-PsSession” command. Background sessions can come in handy if you want to execute multiple commands against many systems. Similar to the other commands, the “New-PsSession” command can run as the current user or using alternative credentials from a non domain system. Examples below.New-PSSession -ComputerName server1.domain.com
New-PSSession –ComputerName server1.domain.com –Credentials domain\serveradmin
If the ActiveDirectory PowerShell module is installed it’s possible to create background sessions for many systems at a time (However, this can be done in many ways). Below is a command example showing how to create background sessions for all of the domain systems. The example shows how to do this from a non domain system using alternative domain credentials.New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "" -Server a.b.c.d -credential domain\user
cd RemoteADS:
Get-ADComputer -Filter * -Properties name | select @{Name="ComputerName";Expression={$_."name"}} | New-PSSession
Listing Background SessionsOnce a few sessions have been established the “Get-PsSession” command can be used to view them.Get-PSSession
Interacting with Background SessionsThe first time I used this feature I felt like I was working with Metasploit sessions, but these sessions are a little more stable. Below is an example showing how to interact with an active session using the session id.Enter-PsSession –id 3
To exit the session use the “Exit-PsSession” command. This will send the session into the background again.Exit-PsSession
Executing Commands through Background SessionsIf your goal is to execute a command on all active sessions the “Invoke-Command” and “Get-PsSession” commands can be used together. Below is an example.Invoke-Command -Session (Get-PSSession) -ScriptBlock {Hostname}
Removing Background SessionsFinally, to remove all of your active sessions the “Disconnect-PsSession” command can be used as shown below.Get-PSSession | Disconnect-PSSession
Wrap Up
Naturally PowerShell Remoting offers a lot of options for both administrators and penetration testers. Regardless of your use case I think it boils down to this:
Use “Invoke-Command” if you’re only going to run one command against a system
Use “Enter-PSSession” if you want to interact with a single system
Use PowerShell sessions when you’re going to run multiple commands on multiple systems
Hopefully this cheatsheet will be useful. Have fun and hack responsibly.
So it’s been an interesting week for me at work as we brought a new customer online. It’s really great to be working with a dynamic team in a rapidly evolving environment. One of the things that’s keeping us ahead of the game is relying on PowerShell when performing repetitive tasks. In this week’s article I’m going to talk about a set of functions I had to come up this week to start PSRemoting remotely.
I’d seen a bunch of postings where people used Schtasks.exe and or PSExec to enable PSRemoting but I didn’t like either of those approaches. I wanted to do it in a more native powershell way. I got a lot of help from Thomas Lee’s blog where he talked about writing registry keys remotely using powershell.
From there I went on to write a set of functions, 5 total, that will perform all the functions required to enable PSRemoting. In order to accomplish the configuration for the WinRM service and the windows firewall remotely I had the functions write entries in the policy node of the registry.
Set-WinRMListener, works by creating 3 registry keys that configure the WinRM service when it restarts.
Restart-WinRM, Uses Get-WmiObject to start and stop the WinRM service.
Set-WinRMStartup, sets the startup type of the WinRM service to automatic.
Set-WinRMFirewallRule, creates 2 registry keys to configure the firewall exemptions required by PSRemoting.
Restart-WindowsFirewall, restarts the windows firewall service to allow the registry configurations to take hold.
Anyway, all the functions are defined in the script on the TechNet gallery. I hope you guys like the functions and get some use out of them. Go ahead and leave a comment or email me if you’re interested in further explanation. Also, feel free to leave comments on the TechNet entry.
Question: Enable-PSRemoting
The Enable-PSRemoting cmdlet configures the computer to receive Windows PowerShell remote commands that are sent by using the WS-Management technology.
By default, on Windows Serverr 2012, Windows PowerShell remoting is enabled. You can use Enable-PSRemoting to enable Windows PowerShell remoting on other supported versions of Windows and to re-enable remoting on Windows Server 2012 if it becomes disabled.
You have to run this command only one time on each computer that will receive commands. You do not have to run it on computers that only send commands. Because the configuration starts listeners, it is prudent to run it only where it is needed.
Beginning in Windows PowerShell 3.0, the Enable-PSRemoting cmdlet can enable Windows PowerShell remoting on client versions of Windows when the computer is on a public network. For more information, see the description of the SkipNetworkProfileCheck parameter.
The Enable-PSRemoting cmdlet performs the following operations:
— Runs the Set-WSManQuickConfig cmdlet, which performs the following tasks:
—– Starts the WinRM service.
—– Sets the startup type on the WinRM service to Automatic.
—– Creates a listener to accept requests on any IP address, if one does not already exist.
—– Enables a firewall exception for WS-Management communications.
—– Registers the Microsoft.PowerShell and Microsoft.PowerShell.Workflow session configurations, if it they are not already registered.
—– Registers the Microsoft.PowerShell32 session configuration on 64-bit computers, if it is not already registered.
—– Enables all session configurations.
—– Changes the security descriptor of all session configurations to allow remote access.
—– Restarts the WinRM service to make the preceding changes effective.
To run this cmdlet, start Windows PowerShell by using the Run as administrator option.
CAUTION: On systems that have both Windows PowerShell 3.0 and Windows PowerShell 2.0, do not use Windows PowerShell 2.0 to run the Enable-PSRemoting and Disable-PSRemoting cmdlets. The commands might appear to succeed, but the remoting is not configured correctly. Remote commands and later attempts to enable and disable remoting, are likely to fail.
Examples
Configure a computer to receive remote commands:PS C:> Enable-PSRemoting
This command configures the computer to receive remote commands.
Configure a computer to receive remote commands without a confirmation prompt:PS C:> Enable-PSRemoting -Force
This command configures the computer to receive remote commands. It uses the Force parameter to suppress the user prompts.
Allow remote access on clients:PS C:> Enable-PSRemoting -SkipNetworkProfileCheck -Force
PS C:> Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
This example shows how to allow remote access from public networks on client versions of the Windows operating system. Before using these commands, analyze the security setting and verify that the computer network will be safe from harm.The first command enables remoting in Windows PowerShell. By default, this creates network rules that allow remote access from private and domain networks. The command uses the SkipNetworkProfileCheck parameter to allow remote access from public networks in the same local subnet. The command specifies the Force parameter to suppress confirmation messages.The SkipNetworkProfileCheck parameter does not affect server version of the Windows operating system, which allow remote access from public networks in the same local subnet by default.The second command eliminates the subnet restriction. The command uses the Set-NetFirewallRule cmdlet in the NetSecurity module to add a firewall rule that allows remote access from public networks from any remote location. This includes locations in different subnets.
“System.DirectoryServices.Protocols“. Here is the link to the Microsoft website were you can download and save the modules locally and load it into powershell.
Import-module ActiveDirectory
$userList= Import-Csv '.\List of Users.csv'
foreach ($userin$userList){ Get-ADUser -Filter "SamAccountName -eq '$($user.sAMAccountName)'"-SearchBase "DC=subdomain,DC=company,DC=com"-Properties Company |% { Set-ADUser $_-Replace@{Company = 'Deliveron'} } }If you then wanted to query AD for those users to make sure they updated correctly, you could use the following query using Get-ADUser:foreach ($userin$userList){
Get-ADUser -Filter "SamAccountName -eq '$($user.sAMAccountName)'"-SearchBase "DC=subdomain,DC=company,DC=com"-Properties Company | Select SamAccountName, Name, Company
}
The MicrosoftWindows Script Host (WSH) (formerly named Windows Scripting Host) is an automation technology for Microsoft Windowsoperating systems that provides scripting abilities comparable to batch files, but with a wider range of supported features. This tool was first provided on Windows 95 after Build 950a on the installation discs as an optional installation configurable and installable by means of the Control Panel, and then a standard component of Windows 98 (Build 1111) and subsequent and Windows NT 4.0 Build 1381 and by means of Service Pack 4. The WSH is also a means of automation for Internet Explorer via the installed WSH engines from IE Version 3.0 onwards; at this time VBScript became means of automation for Microsoft Outlook 97.[1] The WSH is also an optional install provided with a VBScript and JScript engine for Windows CE 3.0 and following and some third-party engines including Rexx and other forms of Basic are also available.[2][3][4]
It is language-independent in that it can make use of different Active Scripting language engines. By default, it interprets and runs plain-text JScript (.JS and .JSE files) and VBScript (.VBS and .VBE files).
Users can install different scripting engines to enable them to script in other languages, for instance PerlScript. The language independent filename extension WSF can also be used. The advantage of the Windows Script File (.WSF) is that it allows the user to use a combination of scripting languages within a single file.
Windows Script Host is distributed and installed by default on Windows 98 and later versions of Windows. It is also installed if Internet Explorer 5 (or a later version) is installed. Beginning with Windows 2000, the Windows Script Host became available for use with user login scripts.
Windows Script Host may be used for a variety of purposes, including logon scripts, administration and general automation. Microsoft describes it as an administration tool.[5] WSH provides an environment for scripts to run – it invokes the appropriate script engine and provides a set of services and objects for the script to work with.[5] These scripts may be run in either GUI mode (WScript.exe) or command line mode (CScript.exe) offering flexibility to the user for interactive or non-interactive scripts.[6]Windows Management Instrumentation is also scriptable by this means.
The WSH, the engines, and related functionality are also listed as objects which can be accessed and scripted and queried by means of the VBA and Visual Studio object explorers and those for similar tools like the various Script Debuggers and Editors. Conversely, VBA is a third WSH engine installed by default.
WSH implements an object model which exposes a set of Component Object Model (COM) interfaces.[7] So in addition to ASP, IIS, Internet Explorer, CScript and WScript, the WSH can be used to automate and communicate with any Windows application with COM and other exposed objects, such as using PerlScript to query Microsoft Access by various means including various ODBCengines and SQL, ooRexxScript to create what are in effect Rexx macros in Excel, Quattro Pro, Microsoft Word, Lotus Notes and any of the like, the XLNT script to get environment variables and print them in a new TextPad document, The VBA functionality of Microsoft Office, Open Office(as well as Python and other installable macro languages) and Corel WordPerfect Office is separate from WSH engines although Outlook 97 uses VBScript rather than VBA as its macro language.[8]
Python in the form of ActiveStatePythonScript can be used to automate and query the data in SecureCRT, as with other languages with installed engines, e.g. PerlScript, ooRexxScript, PHPScript, RubyScript, LuaScript, XLNT and so on. One notable exception is Paint Shop Pro, which can be automated in Python by means of a macro interpreter within the PSP programme itself rather than using the PythonScript WSH engine or an external Python implementation such as Python interpreters supplied with Unix emulation and integration software suites or other standalone Python implementations et al.[9][10] as an intermediate and indeed can be programmed like this even in the absence of any third-party Python installation; the same goes for the Rexx-programmable terminal emulator Passport.[11] The SecureCRT terminal emulator, SecureFX FTP client, and related client and server programmes from Van Dyke are as of the current versions automated by means of the WSH so any language with an installed engine may be used; the software comes with VBScript, JScript, and PerlScript examples.
As of the most recent releases and going back a number of versions now, the programmability of Take Command and 4NT in the latest implementations (by means of “@REXX” and similar for Perl, Python, Tcl, Ruby, Lua, VBScript, JScript and the like and so on) generally uses the WSH engine.[12] The ZOC terminal emulator gets its ability to be programmed in Rexx by means of an external interpreter, one of which is supplied with the programme, and alternate Rexx interpreters can be specified in the configuration of the programme.[13][14] The MKS Toolkit provides PScript, a WSH engine in addition to the standard Perl intepreter perl.exe which comes with the package.
VBScript, JScript, and some third-party engines have the ability to create and execute scripts in an encoded format which prevents editing with a text editor; the file extensions for these encoded scripts is .vbe and .jse and others of that type.
Unless otherwise specified, any WSH scripting engine can be used with the various Windows server software packages to provide CGI scripting. The current versions of the default WSH engines and all or most of the third party engines have socket abilities as well; as a CGI script or otherwise, PerlScript is the choice of many programmers for this purpose and the VBScript and various Rexx-based engines are also rated as sufficiently powerful in connectivity and text-processing abilities to also be useful. This also goes for file access and processing—the earliest WSH engines for VBScript and JScript do not since the base language did not,[15] whilst PerlScript, ooRexxScript, and the others have this from the beginning.
WinWrap Basic, SaxBasic and others are similar to Visual Basic for Applications, These tools are used to add scripting and macro abilities to software being developed and can be found in earlier versions of Host Explorer for example. Many other languages can also be used in this fashion. Other languages used for scripting of programmes include Rexx, Tcl, Perl, Python, Ruby, and others which come with methods to control objects in the operating system and the spreadsheet and database programmes.[16] One exception is that the Zoc terminal emulator is controlled by a Rexx interpreter supplied with the package or another interpreter specified by the user; this is also the case with the Passport emulator.
Any scripting language installed under Windows can be accessed by external means of PerlScript, PythonScript, VBScript and the other engines available can be used to access databases (Lotus Notes, Microsoft Access, Oracle, Paradox) and spreadsheets (Microsoft Excel, Lotus 1·2·3, Quattro Pro) and other tools like word processors, terminal emulators, command shells and so on. This can be accomplished by means of the WSH, so any language can be used if there is an installed engine.
In recent versions of the Take Command enhanced command prompt and tools, the “script” command typed at the shell prompt will produce a list of the currently installed engines, one to a line and therefore CR-LF delimited.[17][18][19]
The first example is very simple; it shows some VBScript which uses the root WSH COM object “WScript” to display a message with an ‘OK’ button. Upon launching this script the CScript or WScript engine would be called and the runtime environment provided.
Content of a file hello0.vbs
WScript.Echo "Hello world"
WScript.Quit
WSH programming can also use the JScript language.
Content of a file hello1.js
WSH.Echo("Hello world");
WSH.Quit();
Or, code can be mixed in one WSF file, such as VBScript and JScript, or any other:
Content of a file hello2.wsf
<job>
MsgBox "hello world (from vb)"
WSH.echo("hello world (from js)");
</job>
Windows applications and processes may be automated using a script in Windows Script Host. Viruses and malware could be written to exploit this ability. Thus, some suggest disabling it for security reasons.[20] Alternatively, antivirus programs may offer features to control .vbs and other scripts which run in the WSH environment.
Since version 5.6 of WSH, scripts can be digitally signed programmatically using the Scripting.Signer object in a script itself, provided a valid certificate is present on the system. Alternatively, the signcode tool from the Platform SDK, which has been extended to support WSH filetypes, may be used at the command line.[21]
By using Software Restriction Policies introduced with Windows XP, a system may be configured to execute only those scripts which are stored in trusted locations, have a known MD5 hash, or have been digitally signed by a trusted publisher, thus preventing the execution of untrusted scripts.[22]
Note: By definition, all of these scripting engines can be utilised in CGI programming under Windows with any number of programmes and set up, meaning that the source code files for a scipt used on a server for CGI purposes could bear other file extensions such as .cgi and so on. The aforementioned ability of the Windows Script Host to run a script with multiple languages in it in files with a .wsh extension. Extended Html and XML also add to the additional possibilities when working with scripts for network use, as do Active Server Pages and so forth. Moreover, Windows shell scripts and scripts written in shells with enhanced capabilities like TCC, 4NT etc. and Unix shells under interoperability software like the MKS Toolkit can have scripts embedded in them as well.
Status as of 2015-09-30. Language has elements of Basic, Forth, Fortran, and others.
SharpCalcScript WSH Engine
Sharp graphing calculators on-board programming language
Sharp S-Basic as ported to windows as NeusSFortran
.scsb
Project Web/FTP Sites
independent programmers
Experimental
2015
Planned
Status as of 2015-09-30. Also subsumes the S-Basic language of Sharp’s Pocket Computers.
There have been suggestions of creating engines for other languages, such as LotusScript, SaxBasic, BasicScript, KiXtart, awk, bash, csh and other Unix shells, 4NT, cmd.exe (the Windows NT shell), Windows PowerShell, DCL, C, C++, Fortran and others.[25] The XLNT language[26] is based on DCL and provides a very large subset of the language along with additional commands and statements and the software can be used in three ways: the WSH engine (*.xcs), the console interpreter (*.xlnt) and as a server and client side CGI engine (*.xgi).[27]
When a server implementing CGI such as the Windows Internet Information Server, ports of Apache and others, all or most of the engines can be used; the most commonly used are VBScript, JScript, PythonScript, PerlScript, ActivePHPScript, and ooRexxScript. The MKS Toolkit PScript programme also runs Perl. Command shells like cmd.exe, 4NT, ksh, and scripting languages with string processing and preferably socket functionality are also able to be used for CGI scripting; compiled languages like C++, Visual Basic, and Java can also be used like this. All Perl interpreters, ooRexx, PHP, and more recent versions of VBScript and JScript can use sockets for TCP/IP and usually UDP and other protocols for this.
The redistributable version of WSH version 5.6 can be installed on Windows 95/98/Me and Windows NT 4.0/2000. WSH 5.7 is downloadable for Windows 2000, Windows XP and Windows Server 2003. Recently[when?], redistributable versions for older operating systems (Windows 9x and Windows NT 4.0) are no longer available from the Microsoft Download Center.
Since Windows XP Service Pack 3, release 5.7 is not needed as it is included, with newer revisions being included in newer versions of Windows since.
What is the difference between CMD and Powershell?
On the first look PowerShell is pretty similar to cmd. They are both used to run external programs like ping or copy, and give you way to automate tasks by writing a script/batch file.
But PowerShell is a lot more than that.
First of all it provides a very rich set of commands (calleds cmdlets) that integrate deeply with windows and most of Microsoft products. Cmdlets like Get-Process which lists active processes.
Another big difference is that the output of this command is not just text, it’s collection of objects. This is way superior to outputting just text, because you can easily query any property of the object, like its name or memory consumption. In cmd you’d have to parse the output.
Another great thing about PowerShell is its integration with .NET. You can easily use all the classes defined in .NET to program any functionality cmdlets are missing.
You can also integrate the powershell runtime into .NET applications with ease and consume Output PowerShell obkects directly.
All in all, PowerShell is cmd on steroids that let’a you automate and manage Windows more easily.
Answer:
The simple answer is that PowerShell is object-oriented, and cmd.exe is string-based. But that’s glossing over the “why is this not just different, but BETTER?”, which is the underlying question.
PSH can create .NET objects on the shell and allow the user to interact with them.
I can, interactively, open an XML file, browse into it using DOM (ParentNode.ChildNode.ChildNode.Attribute), using XPath (SelectSingleNode(“//host”), or [XML] class methods (GetParentNode()), edit it with $xml.CreateElement()/$node.AppendChild(), save it, and fire up in Visual Studio. Interactively.
Normally, I would have to write a program to do it, compile it, run it, (wait for it to bomb out), and then manually open the file in VS.
I can write a script to fire up a new Internet Explorer, have it navigate to a URL, then start filling out fields in forms and expand dynamic content (with great difficulty) using COM automation. Or do the same thing in Excel – take a CSV file, dump it into Excel, reformat it (this table style, add these formulas, that column width) and save it.
I can resize the console window. Or change the title. Or increase the buffer (really? Only 300 lines by default?) Or copy the contents of the buffer, complete with colors.
Answer:
CMD is the older “shell” or “batch” language going back in some form (command.com) to the original DOS operating system.
PowerShell is the new and vastly improved shell and programming language first made available as an add-on and now included (and now enabled) in the Windows operating systems.
While CMD is technically a “programming language” it is a very poor one where it is difficult to define general purpose variables, assign those values, and to use modern control structures.
For example CMD includes “if/then/else”, call (subrouting label or batch file), and an odd form of “for” (really a “foreach”) loop but other than that is largely dependent on “goto” while PowerShell has a excellent flow of control structures.
PowerShell was designed to off an EFFECTIVE superset of CMD functionality which it come close to doing directly AND it can call CMD for anything that isn’t available directly.
PowerShell supports not only calling CMD as an “external program” but calling any other pre-existing or new program as an external extension to its own functionality.
PowerShell has direct access to almost all of DOTNET, and easy access to COM and even C#, F# and other DOTNET languages.
PowerShell passes and returns OBJECTS (structured data with methods, events, and properties) to other commands and returns these objects from most commands as well while CMD produces only text.
This idea of ‘objects’ is extremely important as is removes the need to “parse” results based on line position or characters on the lines – -instead one merely queries the objects for the properties available.
PowerShell also now includes LITERALLY THOUSANDS of functions, cmdlets, and other funtionality and is extemely extensible.
PowerShells regular expressions are comparable to those in Perl, or perhaps arguably more powerful can capable. One of the main things about regular expresions in Perl is that besides being very extensive they are a NATURAL part of the language — PowerShell comes close to this ideal of integration established by Perl for regular expressions.
PowerShell includes extensive and excellent error handling.
PowerShell includes extensive, extensible, and excellent Help.
PowerShell’s main deficiencies are these:
Not available by default on every version of WIndows still commonly in use (Win2003/XP
Not enabled even when present until the latest versions of Windows — Win2012 and Windows 8.
Answer:
Cmd is an antiquated CLI that mainly executes console programs that live on your file system, and processes the output they provide as text. Powershell is an object oriented shell/programming language that processes objects. It uses a ‘pipeline’ approach, much like bash, except instead of processing text in the pipeline, it processes objects. This allows you to call upon that object’s properties and methods, making it a very powerful tool to have in the toolset. It’s a .NET language, so you can actually build full featured apps with it, like Windows Forms apps, WPF apps etc, as well as more traditional scripts.
Powershell can also invoke the same command line utilities that CMD does, such as ping or netstat, but it also has Cmdlets. Cmdlets are not console programs, but actually functions that either live inside compiled DLLs on your system, typically written in C#, or Powershell based functions that live inside Powershell modules.
Powershell can do everything CMD does and much, much more. In fact one of its primary purposes was to replace both CMD, batch files and vbScripts.
Answer:
CMD is basically an updated version of DOS prompt. It’s very simple, and its only commands are related to file management (which is not needed anymore as we have Windows Explorer), everything else is done by executing .exe files or other batch files which are made of the same commands. Powershell, on the other hand, is designed for automation. It has much more advanced commands which can often do what you can’t do with CMD, or which is incredibly hard to do with it. For example, the command Add-AppxPackage installs a Windows Store application from an .appx file – that’s called sideloading. This action is very complicated because of the nature of Windows Store apps, which are deeply itegrated with Windows Store and the shell itself. It can’t be done with CMD at all.
Powershell also has a more advanced support for variables, objects, making it as powerful as other scripting languages. Batch is also technically a scripting language, but it only has very simple functionality: even loops need to be implemented using the “goto” command, which is one of the many things that make the code hard to read.
Answer:
You can run CMD commands in Powershell, but not the opposite.
POwershell is much more powerful and allows a much more modern and sound scripting.
Then Powershell uses object, not strings.
In other words, you can take the output of a command and reuse it in other commands much more easily than how you’d do with a traditional CMD.
Then Powershell comes from C#, so it’s much more powerful as a programming tool.
Answer:
Just some additional information, since powershell is integrated with .net so you can do some inline c# with powershell to make it even more powerful which you can never have a chance with cmd prompt. Also it can start jobs to make parallel processing of different {script block}.
Answer:
There’s a fairly large difference between these two. At the end of the day, they both execute sequences of actions; PowerShell is an extreme evolution past CMD, much more in line with what a ‘proper’ shell should be.
PS is great for its integration with .NET.
Answer:
roughly 30 years of progress in scripting languages.
Really, cmd has not any significant progress since the DOS era. It was replaced, first by Windows Scripting Host and now by powershell.
I seem to vaguely recall QBasic and earlier dialects.. not sure where those fit in. At least you could rename files across directories.
Answer:
PowerShell has a pipeline based on typed .NET objects, while cmd (and most other command line processors, like Unix based shells, usually) have a pipeline based on strings of characters.
Being a Windows user, you don’t have to deal with the command line interface for daily activities. That being said, for any advanced tasks the command line provides greater flexibility and control over the task. In fact, that’s the sole reason why Windows has both the Command Prompt and PowerShell. Since both are command line interfaces, the PowerShell and Command Prompt may look similar at first glance. But there are significant differences between both of them. Let us get to know what PowerShell and Command Prompt actually mean and how PowerShell differs from Command Prompt.
What is Command Prompt
Command Prompt is the default command line interface provided by Microsoft starting from Windows NT (Windows NT 3.x and above). It is a simple win32 application that can interact and talk with any win32 objects in the Windows operating system. It has a user-friendly command structure and is widely used to execute batch files, troubleshoot Windows problems, perform advanced actions, get information, etc. Due to its user interface and command line structure, many call it “the DOS prompt,” though it doesn’t have anything to do with MS-DOS.
What Is PowerShell
The first version of PowerShell, which is based on the .NET framework, was released way back in 2006 and is much more advanced than the Command Prompt. PowerShell has many different advanced features like command piping, task automation, remote execution, etc.
On the other hand, PowerShell deeply integrates with the Windows operating system while still providing interactive command line interface and scripting language. Considering the deep integration and support for the scripting language, it is often used by system administrators and IT professionals to perform task automation and configuration management.
How PowerShell Differs from Command Prompt
The PowerShell is much more advanced in terms of features, capabilities and inner workings when compared to the legacy Command Prompt. In fact, almost every under-the-hood module of Windows can be exposed by PowerShell, thus making it a useful tool for IT professionals, system administrators, and power users.
When I say PowerShell, most of you may think of the standard command-line interface, but Windows also comes with PowerShell ISE (Integrated Scripting Environment) which helps you create custom and complex PowerShell scripts for all kinds of works.
Moreover, PowerShell uses what are known as cmdlets. These cmdlets can be invoked either in the runtime environment or in the automation scripts. Unlike the Command Prompt or even the *nix shell, the output generated from a cmdlet is not just a stream of text (strings) but a collection of objects.
Since PowerShell treats them as objects, the output can be passed as an input to other cmdlets through the pipeline. This allows you to manipulate the data as much as you want without seeking the help of complex Reg expressions. This is just not possible in the Command Prompt.
When you compare all this to the legacy Command Prompt, you will find it painfully inferior to the PowerShell in terms of both functionality and how much you can do with it.
But all this power of PowerShell comes at a cost; that is the learning curve. If you don’t mind the steep learning curve, then do give PowerShell a try. Of course, if you are entering into the realm of system administration, then you definitely need to learn PowerShell to make your life easier.
If you are an average Windows user who hardly uses the Command Prompt, then you might not get much out of the PowerShell.
What problem did MS solve by creating PowerShell? [closed]
I’ve been trying to write some deployment scripts using PowerShell and I’ve been less than enthused by the result. I have a co-worker who loves PowerShell and defends it at every turn. Said co-worker claims PowerShell was never written to be a strong shell, but instead was written to:
a) Allow you to peek and poke at .NET assemblies on the command-line (why is this a reason for PowerShell to exist?)
b) To be hosted in .NET applications for automation, similar to DCOP in KDE and how Gnome is using CORBA.
c) to be treated as “.NET script” rather than as an actual shell (related to b).
I’ve always felt like Windows was missing a decent way to bang out automation scripts. cmd is too simplistic in many cases, and WSH is too obtuse (although the combination can be used successfully, I’m not a fan). When I first heard about PowerShell I felt like Windows was finally getting a decent shell that would be able to help with automation of many tasks, but recent experiences, and my co-worker, tell me otherwise.
To be clear, I don’t take issue with the fact that it’s built on .NET, or that it passes objects around rather than text (despite my Unix background :]), and I’m not arguing that PowerShell is useless, but from what I can see, it doesn’t solve the problem I was hoping it would solve very well. As soon as you step outside of the .NET/Powershell world, things quit being nice and cozy for you.
So with all that out of the way, what problem did MS solve by creating PowerShell, or is it some political bastard child as I suspect? I’ve googled and haven’t hit upon anything that sufficiently answered that for me, but the more citations the better.
Answer:
PowerShell was actually built as several things: A mature and extensible automation platform and a modern administration shell.
The former is primarily used for the administration GUIs for Exchange and other server products of recent times. The GUI is just a wrapper around PowerShell which does the heavy lifting behind (kind of like UNIX GUI programs come to be, as a wrapper for a commandline program).
Jeffrey Snover (PowerShell inventor) elaborates a little on how PowerShell was created with which goals and problems it should solve.
In my opinion, PowerShell as a shell is clearly intended as a replacement for cmd (easy to see) and Windows Script Host (Windows Script Host didn’t get much attention in recent years, even though it had similar concepts as .NET back in its day [one platform, multiple languages with ActiveScripting], but with .NET Microsoft basically put that to rest and resurrection probably wasn’t an option for them).
It unifies most aspects of Windows administration in common concepts and methods you only have to learn once. Also, the power in PowerShell for me stems greatly from it passing around objects which might explain why you get into problems when you step out of the .NET/PowerShell world where you only get a String[] from a command. But for many things you would call an external program for in cmd, there is a cmdlet which will do it for you.
Answer:
As a developer, I can tell you I no longer have a bunch of ConsoleApplication42 projects laying around in a folder.
As a developer at a small company where I pretty much do all things IT (DBA, manipulate routers, pull call detail records from the switch, monitor and graph bandwidth for customers, etc…) I can tell you that PowerShell fills a sorely needed gap in Windows and the fact that it’s built on .NET provides a seamless upgrade path when the PowerShell pipeline is too slow to handle millions of iterations or a more permanent, strongly typed implementation is needed.
Anyway, I guess the question is why are you switching to PowerShell if you don’t have a pressing need? I mean it’s good to learn it now since it’s basically the new management interface for all things Microsoft. But if that doesn’t affect you then don’t bother if you don’t think you’re gaining anything.
EDIT (In response to comments below)
It sounds like you’re trying to use the .NET Process class to launch an exe and redirect it’s stdout so it can be read by the caller. I agree that is a pain in .NET but fortunately PowerShell does all this for you pretty simply. As for capturing the result and still writing it to the display, that’s pretty simple too though the command isn’t a very well-known one because it isn’t used that often. Here’s an example:
# I always find it easier to use aliases for external commands
Set-Alias csc C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe
# Create some source file
Set-Content test.cs @"
class Program {
static void Main() {
System.Console.WriteLine("Hello World");
}
}
"@
# Call CSC.EXE
# the output of csc.exe is written to results.txt and piped
# to the host (or select-string if you prefer)
csc test.cs | Tee-Object -file results.txt
# Check for errors
if ($LASTEXITCODE) {
# this is where community extensions would come in
# handy. powershell 2.0 also has a command to send
# mail but in 1.0 you can grab one from poshcode.org
}
Windows PowerShell is a task-based command-line shell and scripting language designed especially for system administration that is used by information technology professionals on a regular basis. Although it is developed by Microsoft and is widely available, it does have some potential drawbacks that IT professionals may not appreciate. If you are learning how to use the language, issues could arise at some point.
Object-Based
One of the potential disadvantages of using Windows PowerShell is that it is object-based. With most shells, you rely on text-based commands to get the job done when writing scripts. If you switch to Windows PowerShell from some other type of shell, you’ll have to get used to a different way of thinking about things. This can be a problem that takes some time to get past for some users.
Security Risks
Another potential drawback of using Windows PowerShell is that it can create some potential security risks. Many IT professionals use it as a way to connect remotely to other computers and servers. When engaging in this process, PowerShell can leave some holes open for security breaches. This creates a potential for viruses, malware or other harmful programs to be installed in the server. If someone else who knows Windows PowerShell gets involved, it could cause problems.
Web Server
Another issue with Windows PowerShell is that it requires you to run a Web server on your server when utilizing remote functionality. This takes up additional space on a server. In many cases, companies will not want to take up more room and designate more resources to this on their own servers. If you are an IT professional working for a company, you may have to get approval from a higher-up before this is allowed.
Considerations
Although Windows PowerShell does have some potential drawbacks, it also has a few advantages. For example, since it is developed by Microsoft, it is being integrated more and more into Microsoft products and services. Windows PowerShell is also versatile and easy to administrate once you learn the basics of the scripting language. It also gives you the ability to run specific commands that are designed to run only on local networks if you are using the remote connection function.
How PowerShell Differs From the Windows Command Prompt
Windows 7 added PowerShell, a more powerful command-line shell and scripting language than the Command Prompt. Since Windows 7, PowerShell has become more prominent, with it even becoming the default choice in Windows 10.
PowerShell is more complicated than the traditional Command Prompt, but it’s also much more powerful. The Command Prompt is dramatically inferior to shells available for Linux and other Unix-like systems, but PowerShell competes favorably. In addition, most Command Prompt commands are usable in PowerShell, whether natively or through aliases.
PowerShell is actually very different from the Command Prompt. It uses different commands, known as cmdlets in PowerShell. Many system administration tasks — from managing the registry to WMI (Windows Management Instrumentation) — are exposed via PowerShell cmdlets, while they aren’t accessible from the Command Prompt.
PowerShell makes use of pipes—just as Linux does—that allow you to pass the output of one cmdlet to the input of another cmdlet. Thus, you can use multiple cmdlets in sequence to manipulate the same data. Unlike Unix-like systems—which can only pipe streams of characters (text)—PowerShell pipes objects between cmdlets. And pretty much everything in PowerShell is an object, including every response you get from a cmdlet. This allows PowerShell to share more complex data between cmdlets, operating more like a programming language.
PowerShell isn’t just a shell. It’s a powerful scripting environment you can use to create complex scripts for managing Windows systems much more easily than you could with the Command Prompt.
The Command Prompt is essentially just a legacy environment carried forward in Windows—an environment that copies all of the various DOS commands you would find on a DOS system. It is painfully limited, can’t access many Windows system administration features, is more difficult to compose complex scripts with, and so on. PowerShell is a new environment for Windows system administrators that allows them to use a more modern command-line environment to manage Windows.
When You Would Want to Use PowerShell
So, when would an average Windows user want to use PowerShell?
If you only rarely fire up the Command Prompt to run the occasional ping or ipconfig command, you really don’t need to touch PowerShell. If you’re more comfortable sticking with Command Prompt, it’s not going anywhere. That said, most of those commands work just fine in PowerShell, too, if you want to try it out.
However, PowerShell can be a much more powerful command-line environment than the Command Prompt. For example, we’ve shown you how to use the PowerShell environment built into Windows to perform a search-and-replace operation to batch rename multiple files in a folder—something that would normally require installing a third-party program. This is the sort of thing that Linux users have always been able to do with their command-line environment, while Windows users were left out.
However, PowerShell isn’t like the Linux terminal. It’s a bit more complicated, and the average Windows user might not see many benefits from playing with it.
System administrators will want to learn PowerShell so they can manage their systems more efficiently. And if you ever need to write a script to automate various system administration tasks, you should do it with PowerShell.
PowerShell Equivalents of Common Commands
Many common Command Prompt commands—from ipconfig to cd —work in the PowerShell environment. This is because PowerShell contains “aliases” that point these old commands at the appropriate new cmdlets, running the new cmdlets when you type the old commands.
We’ll go over a few common Command Prompt commands and their equivalents in PowerShell anyway—just to give you an idea of how PowerShell’s syntax is different.
Change a Directory
DOS: cd
PowerShell: Set-Location
List Files in a Directory
DOS: dir
PowerShell: Get-ChildItem
Rename a File
DOS: rename
PowerShell: Rename-Item
To see if a DOS command has an alias, you can use the Get-Alias cmdlet. For example, typing Get-Alias cd shows you that cd is actually running the Set-Location cmdlet.
Question: How to change the listening port for Remote Desktop
To change the port that Remote Desktop listens on, follow these steps.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
Start Registry Editor.
Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber
On the Edit menu, click Modify, and then click Decimal.
Type the new port number, and then click OK.
Quit Registry Editor.
Restart the computer.
Note When you try to connect to this computer by using the Remote Desktop connection, you must type the new port. Maybe you have to set the firewall to allow the new port number before you connect to this computer by using the Remote Desktop connection.
Question: Change Remote Desktop RDP Port
Port 3389 is the home of the remote desktop protocol that powers Remote Desktop Services on all modern versions of Windows. If your system has Remote Desktop enabled, it is listening for connections on port 3389. Since this port is both well known and can be used to attack accounts, it is low hanging fruit for script kiddies and bots looking for an easy target.
Theoretically on a system that does not have an account lockout policy in place, which by the way is not a system default, the RDP protocol can be used to get the administrator password with brute force. Brute force is a fancy way of saying trying all possible passwords. If the system never locks out the account then time is the only barrier to eventually getting you password and logging in.
The first defense is to implement a good account lockout policy but that does not solve the entire problem. Any administrator of a public facing Windows web server will notice that their server is continiously attacked by bots looking for an easy target. The bots will often lock out your accounts which can be very annoying.
To protect your system from the bots and script kiddies I always reccomend changing the default RDP port. This will not fool an intelligent attacker but it will weed out the noise.
Follow these steps to change the Remote Desktop server port:
Open up Registry Editor by clicking on the Start Button, type in regedit and then hit Enter.
In Registry Editor, navigate to HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, Terminal Server, WinStations and RDP-Tcp.
Right click on the PortNumber dword and select Modify.
Change the base to Decimal and enter a new port between 1025 and 65535 that is not already in use.
Click OK and reboot.
Make sure to reboot to activate the change.
Keep in mind that the next time you want to connect to your system with RDP you will need to provide the port number. You can do that from the Remote Desktop client by appending a colon after the host name or ip address followed by the port number. For example, if I have a computer with host name of tweak with RDP running on port 1234 I would use tweak:1234 in the remote desktop client hostname field.
Question: Windows Remote Desktop: Configuring Your Firewall and Router
Windows Remote Desktop: Configuring Your Firewall and Router
By Eric Geier
In Part 1 of this tutorial series, we configured Windows to accept remote desktop connections, so we can log into and use a PC anywhere in the World with Microsoft’s Remote Desktop Connection client application. In Part 2, we configured Windows to accept remote connections via a Web browser, so the client application doesn’t have to be installed on the computer from which you are connecting.
However, neither of these methods will work until your firewall is configured to allow remote connections. This tutorial addresses that. Plus, to connect to your PC via the Internet, your router must be properly configured.
In this tutorial, we’ll tell the firewall on the PC that’s hosting the remote connection that it is okay to allow incoming connections on the appropriate port. We’ll also tell your router where to forward remote desktop connections. Let’s get started.
Letting the Traffic Past Your Firewall
Since you will be trying to connect to your PC from the local network or Internet, your firewall software must be configured to let the traffic through. Enabling the Remote Desktop feature on Windows automatically configures Windows Firewall with the appropriate settings; however, you must manually configure any other third-party firewall software you have installed on your computer. To do this, add UDP port 3389 (which Remote Desktop uses) to your firewall’s authorized list. If needed, refer to the help and documentation of the firewall program for assistance.
It’s possible to change your Windows Firewall settings and accidentally mess up the setting automatically made when you enabled Remote Desktop. Therefore, to be on the safe side we’ll verify Remote Desktop connections can pass through.
If you are also setting up Web access to the Remote Desktop Connection, you must add TCP port 80 (or the port you choose for IIS if you changed from the default) to your Windows Firewall and any other third-party firewall. Windows doesn’t automatically add this port to the authorized list, so you will have to do it yourself.
Follow these steps in Windows Vista to verify the Windows Firewall settings or add the Web access port:
On the Control Panel window, under the Security category, click the Allow a program through Windows Firewall link. If User Account Control is enabled, select an account and enter a password, if required, and click Continue on the prompt.
On the Windows Firewall Settings window that opened, click the General tab.
Make sure the Block all incoming connections check box is NOT checked; as Figure 1 shows.
Click the Exceptions tab and scroll down to make sure the Remote Desktop item is checked; as Figure 2 shows. This verifies Windows Firewall is set to allow the traditional Remote Desktop Connections.
If you are setting up Web access with IIS, as well, click the Add Port button. Then, on the Add a Port dialog box, type in a Name (such as Remote Desktop Web Connection) and enter the default port 80 or the port you manually changed IIS to into the Port Number field, select TCP for the Protocol, and click OK.
When you’re done, click OK.
Even if all incoming connections are blocked, exceptions can be made(Click for larger image)
If you’re using Windows XP, here’s how to verify the Windows Firewall settings and/or add the Web access port:
Click the Start button and choose Control Panel.
On the Control Panel window, click the Security Center category.
On the Windows Security Center window that opened, near the bottom of the window, click the Windows Firewall icon.
Make sure the Don’t allow exceptions check box is NOT checked.
Click the Exceptions tab and scroll down to make sure the Remote Desktop item is checked.
If you are setting up Web access with IIS, as well, click the Add Portbutton. Then on the Add a Port dialog box, type in a Name (such as Remote Desktop Web Connection) and enter the default port 80 or the port you manually changed IIS to into the Port Number field, select TCP for the Protocol, and click OK.
When you’re done, click OK.
If you are using other third-party firewall utilities, make sure you add these ports to them as well. If you find you’re having problems later when connecting, consider disabling all firewall software except Windows Firewall.
Configuring Your Router
If your PC isn’t directly connected to your Internet modem, and it is running through a wired or wireless router, you must configure the router to connect to the Remote Desktop connection via the Internet. This configuration lets your router know where to direct Remote Desktop connections that originate from the Internet.
Configuring your router consists of setting it to forward data, which comes in to certain ports, to the computer you have set up with the Remote Desktop Connection. For either Windows XP or Vista, TCP port 3389 (which Remote Desktop uses) must be forwarded to the Remote Desktop PC. If you are setting up Web access, you also must forward TCP port 80 (or the non-default port you set) to the host computer.
If you aren’t sure exactly how to set up these port forwards, these steps should help:
Access your router’s Web-based configuration utility by bringing up your Web browser, typing in the IP address of your router, and pressing Enter. If you don’t know the IP address, see your router’s documentation or reference the Default Gateway value that’s given in the connection status details of Windows.
When prompted, enter the username and password of your router. You should have set these login credentials when you had set up your router; however if not, you can reference the default values in the router’s documentation.
Find the Virtual Server or Port Forwarding tab of the router’s administration screens.
Enter the port details, for each port you need to forward (discussed in the previous paragraphs) by entering information into the appropriate text boxes or selecting options from list boxes. Figure 3 offers an example. Port details, for each port to be forwarded(Click for larger image)You may have to enter a name, which would be for your reference, like remote desktop or remote desktop Web access. Sometimes you can pick the computer (identified by the Computer Name) you want to forward to from a drop-down menu list, or you may have to enter the IP address of the computer. You can find your computer’s IP address by referencing the connection status details of Windows. Lastly, you’ll probably have to enter the port you want to forward, which were given earlier for both Remote Desktop and Web access.
Click a Save or Apply button.
Now you must make sure the port(s) are always forwarded to the correct computer. If you are using dynamic IP addresses on your local network (which is the default method), meaning they’re automatically assigned to your computers using the router’s DHCP server, you’ll need to do some additional configuration. You must assign a static IP address to at least the computer that’s going to be hosting the Remote Desktop Connection. This is because the IP address you just set up to forward the ports to will sometime be given to another computer or become unused if it’s being automatically assigned.
You have two ways you can go about giving your computer a permanent IP address. You can reserve an IP address for the computer in the router’s configuration utility, if your router supports it. This is preferred so you don’t have to change your computer’s actual settings and connecting to other networks will be much easier. However, if the feature isn’t available you can always manually assign your computer (network adapter) with a static IP address in Windows, such as Figure 4 shows.
Stay tuned-in for the final installment of this series, where we’ll connect to the remote desktop connection via the client application and via Web access. Plus, we’ll discuss how to overcome having a dynamic (changing) IP address.
About the Author: Eric Geier is the Founder and President of Sky-Nets, a Wi-Fi Hotspot Network. He is also the author of many networking and computing books, including Home Networking All-in-One Desk Reference For Dummies (Wiley 2008) and 100 Things You Need to Know about Microsoft Windows Vista (Que 2007).
Question: Change RDP Port of Windows 2012 R2 server running in amazon AWS [duplicate]
By default, remote desktop connections on windows use port 3389. If you find the need to change this port, the following should help. Make sure you have “Allow remote connections to this computer” checked under “System Properties > Remote” before you begin.
In my experience, you should avoid changing the mapped port for core Windows services if possible, as this can cause numerous configuration and management issues. Other options include:
– Using port mapping (forwarding) on your router (e.g. externalip:10000 -> serverip:3389), however not all routers offer this functionality.
– Installing a third party remote desktop app, like Chrome Remote Desktop or LogMeIn, however these require specific software and/or subscriptions
– Deploying a server/PC as a RDP “gateway”. You then access all further RDP hosts from this first point of contact.
– Using a RD gateway/RD Web access. This requires a server with the appropriate role installed, but can optionally be configured with two-factor authorisation like Duo.
To check what port your RDP is currently listening on, use the netstat command in an elevated command prompt.
netstat -abo
This will show information about current network connections and listening ports, as well as associated executables and processes. You’ll see port 3389 bound to “svchost.exe” on “TermService”.
To change the bound port you’ll need to open an elevated command prompt and run regedit.
regedit
Navigate to the PortNumber setting.
HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > RDP-Tcp
Right click on the “REG_DWORD” named “PortNumber” and hit “Modify”. Change the base to Decimal and enter the new port (between 1025 and 65535). You can use NetStat to check if a particular port is already bound to a process.
Once you’ve changed the value, exit RegEdit and either reboot the computer, or simply restart the Remote Desktop Services service using the “Services” snap-in in “Computer Management”. You can confirm the port has been changed by running netstat again (in my case, to 10000).
Finally, open up Windows Firewall and add a new inbound rule for the new port. You won’t be able to change the existing rule as that’s a core system rule, but copy across the values into a new rule and you’ll be good to go.
Question: How to change Remote Desktop port (RDP) on Windows server on VPSie
This short tutorial will explain how to change the RDP (Remote Desktop port) server is listening on for use with Private Cloud Solution (PCS) with one public IP when client have more than Windows guests within his Private Cloud
In this example we will change default port 3389 with port 6000:
1- Login from console to DB server –
Click on the Windows VPSie you want to change the port for – Access then console access
Click Ctrl-ALt-Delete so you get login prompt:
User username : Administrator / Password emailed to you upon VPSie creation (If not changed by you)
Once logged in :
2- Click simultaneously on the Windows logo + R to open the “Run” dialog and execute the “cmd” command – Valid for 2012 R2, Or CMD on 2008 server editions.
3- Open the registry editor by typing the “regedit” command
4- Search for this registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
5- Double-click or right-click on the “PortNumber” registry subkey, select the decimal base and type the port number of your choice (the default port is 3389, in this example, we selected port 6000). Click on “Ok” to save your selection.
6- Exit the registry editor
7- Restart your server
Note: Firewall is already enabled by default and allowing RDP connection on all VPSie(s).
Upon reboot you should be able to access RDP on the new port 6000.
In case new port is not allowed in Windows firewall – this is a quick method to add it :
Select ports –> Input 6000 –> allow ALL incase you want to RDP one that port locally or public –> give it a name –> you done.
Question: Change Remote Desktop Port back to 3389
Hello Everyone,
I need a bit of ideas on a decent way to push out a GPO to change/verify that the RDP port on workstations are the default 3389.
The old Network admin changed the ports and had wan ip’s pointing to them. This now makes it tricky to RDP to the machines w/o knowing the port.
I figured I could run a registry script to change the port.
Any ideas?
Answer:
Hi Andrew,
First, you need to find out how the previous admin changed the port: script? GPO? because it might get re-applied.
Second, you can check the registry key for the currently used port for RDP (same key for WIndows 7 too): SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumbersource: http://support.microsoft.com/kb/306759
The easiest thing to do for applying the “new” RDP port to the entire domain pc will be through GPO:
Computer Configuration > Preferences > Windows Settings > Registry
Just add a new registry item pointing to the above key:
Value data: 3389 (make sure to select the base as Decimal on bottom right)
Question: Change Remote Desktop Gateway Port
Q: Can I change the port that Remote Desktop Gateway uses?
A: By default, the Remote Desktop (RD) Gateway component that encapsulates RDP in HTTPS packets listens on port 443 (for TCP) and port 3391 (for UDP). You can use the RD Gateway Manager utility to change this as follows:
Right-click the RD Gateway server name in the navigation pane and select Properties.
Select the Transport Settings tab.
Modify the HTTP and/or UDP port number. Set the custom port value to the same port if you change them, because there’s no way to do so in the client.
Specify different custom ports for UDP versus TCP, then click OK.
Note that two firewall exceptions are enabled by default; however, they use the default ports, so you’ll need to add your own firewall exceptions for TCP and UDP for the custom port you selected.
When you connect from a client, you need to add the custom port to the end of the gateway server name, preceded by a colon (:); for example, mygateway.domain.com:9999. Note that this is only an RDP client that supports RDP 8.0 or later.
If you’re using RemoteApp, you need to manually update the gateway in the RDP file with the correct port because you can’t change it via Server Manager to specify a custom port for the gateway. You can modify the port used for the gateway by connecting to the Remote Desktop Session Host and navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\\DeploymentSettings, then editing the DeploymentRDPSettings value to add the port to the gatewayhostname:s:mygateway.com:9999 part of the string. Note that you must set this before you publish any applications. A nicer way is to use PowerShell:
We can easily change remote desktop listening port to some other port than the default 3389.
By default RDP listens on TCP 3389. Once we change this port to some other port , We may need to restart the system to activate the new listening port .
Then click on PortNumber and select radio button Decimal which will show value in Decimal. Now enter a desired port number and close the registry editor.
To activate this new port , press Windows+R on keyborad which opens up run window. Type services.msc in run window and press enter now we can restart “Remote Desktop Services” from Sevices list . This will cause any existing remote desktop connection to close and one may need to reopen remotedesktop on new port by entering IPADDRESS:NEWPORT on Remote Desktop client (mstsc)
Remote Desktop is a very useful feature of Windows operating system that allows the user to remotely connect to the computer from any computer to the computer where RDP is enabled. By default, Remote Desktop uses port 3389. Since this is a common port, and if RDP is enabled on Windows, it will use this port which poses a security risk therefore it is highly recommended to change this port.
You can implement an account lockout policy to lock the account after (X Number of failed log-in) attempts. However, you don’t want anyone to login to the RDP and attempt brute force attacks.
How to Change RDP (Remote Desktop Port)
There are two methods to change the default Remote Desktop Port. Let’s have a look at both methods.
Method 1: Change RDP through Microsoft Fix It Utility
Click on this link to download Microsoft Fix it utility. When the file download dialogue box appears, click “Run”.
Follow the instructions in the Fix it wizard. Type a new port number between 1025 and 65535 in the PortNumbertext box. Make sure the port is not in use already, otherwise it can conflict and won’t work.
PRO TIP: If the issue is with your computer or a laptop/notebook you should try using the Reimage Plus Software which can scan the repositories and replace corrupt and missing files. This works in most cases, where the issue is originated due to a system corruption. You can download Reimage Plus by Clicking Here
Method 2: Change RDP through Registry Editor
Hold the Windows Key and Press R to open Run Dialog, In the run dialog box type regedit and click the OKbutton.
When registry editor opens, navigate to the following registry key:
On the Edit menu, click Modify, and then click Decimal. Type a new port number between 1025 and 65535, and click OK.
Note: When you change Remote Desktop Port, you must type the new port number when you try to connect to this computer. If you have a firewall installed, you may need to configure your firewall to allow the new port before you can connect to this computer using Remote Desktop.
Question: How to change default Remote Desktop listening port
By default, Remote Desktop Protocol (for Windows XP and Server 2003) listens on TCP port 3389.
Each PC needs to listen on a different port in order for the Remote Desktop request coming in from the client PC to be forwarded by your router to the proper host PC.
To make a host PC listen on a port other than the default port 3389, you must edit the registry.
IF YOU’VE NEVER EDITED THE REGISTRY BEFORE BE CAREFUL!
EDITING THE WRONG FILES CAN PERMANENTLY DESTROY YOUR OPERATING SYSTEM! :hotouch:
Run Regedit and go to this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\Terminal Server\WinStations\RDP-Tcp
Find the PortNumber subkey and notice the value of 0x00000d3d (3389).
Modify the port number to any unused port (ie-3390 or d3e in hex) and save the new value.
Reboot for this change to take effect.
Now you need to configure your router to forward the different port requests to the proper local IP address.
By default, Remote Desktop listens on port 3389 (via TCP). Using a quick registry tweak, you can change that to any other valid port. The following steps describe the process:
Start Registry Editor (by default, this is located at c:\windows\regedit.exe).
Go to the following registry key: HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp
Open the PortNumber subkey.
Pick the Decimal Base option.
Enter the new port number, and then click OK.
Does Remote Desktop send traffic over any other ports?
Primary remote desktop traffic will go over the one port defined above. If sound is enabled, streaming will be attempted over UDP directly. If this connection can’t be made, Remote Desktop will stream sound over a virtual channel via the main remote desktop port.
No other ports are used.
How to connect to a non-standard remote desktop port
To connect to a different port than the default 3389 RDP port, specify the port using one of the following formats:
<computername>:<port> example: computer:23389
<ip address>:<port> example: 192.168.1.1:23389
Question: HOW TO CHANGE THE DEFAULT RDP (REMOTE DESKTOP) LISTENING PORT ON YOUR WINDOWS VPS?
By default Windows machines are remotely accessible via Remote Desktop on TCP port 3389. In certain situations changing the Remote Desktop port is useful, especially when you receive a huge number of failed Remote Desktop login attempts on default port. In order to change the default port of Remote Desktop, you’ll need to alter the registry of your server. Registry changes may cause some serious problems in your server when performed incorrectly, so be careful while performing the steps mentioned in this article.
Furthermore, to maintain the access to your server after changing the Remote Desktop port, be sure that you also change the port in Windows Firewall’s Remote Desktop Services rule OR create new rule with new RDP port by referring to this article. Otherwise, Windows firewall won’t allow you to access your server using new Remote Desktop port.
Question: CHANGE WINDOWS REMOTE DESKTOP (RDP) PORT
Change Windows VPS RDP port.
This article is based on Windows Server 2003 R2. Most of the steps should be similar for newer Windows Server versions.
Warning: Changing the default RDP port should be used as an addition to normal server security measures – not as an alternative.
Changing the default RDP port will require firewall and registry changes on the VPS, and changes to the RDP file configuration.
Warning: making these changes will prevent the default RDP file for your VPS(found in mPanel) from connecting to the VPS unless it is modified. If you are not sure you understand the changes being made, please back up your VPS first, or don’t change anything.
Contents
Part 1. Configuring The RDP File
1.1 Log into mPanel and browse to the remote access page for the VPS. Download the RDP file for your VPS, saving with a file name which can be easily identified as a modified version. e.g. newrdpport.rdp
1.2 Locate the downloaded RDP file to used to log into the VPS, then right-click it and select Edit from the menu dialogue.
1.3 In the Computer: field enter the IP address of your VPS followed by a colon and the new RDP port number you will be using. e.g. 103.1.188.189:23654
1.4 Click the Save button in the ‘Connection settings’ section just below where you entered the VPS IP and new RDP port to use.
Part 2. Configuring the VPS Firewall
2.1 Open the Windows Firewall configuration dialogue on the VPS. Click the Start menu and go to Settings -> Control Panel -> Windows Firewall(usually the last Control Panel item).
2.2 Click the ‘Exceptions’ tab in the Windows Firewall window.
2.3 Click the ‘Add Port’ button to bring up a new configuration window.
2.4 Enter a name for the new firewall rule being created, and the same port number entered into your RDP file in Part 1.3 of the guide. Leave the default TCP option selected and click OK.
Example:
Name: Alternate RDP Port
Port Number: 23654
Note: If you will only be accessing your VPS from a static IP address(or addresses), you can add the IP address in the ‘Change Scope’ section using the ‘Custom List’ option for additional security.
2.5 Click the OK button to exit the Windows Firewall configuration and save the changes.
Part 3. Editing the Windows registry on the VPS
3.1 Open the registry editor on the VPS by clicking the Start menu, go to Run… and type in ‘regedit’ (without including the quotation marks) and click OK or hit the enter key.
3.2 In the registry editor, navigate to the registry key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’.
3.3 Scroll down the right side of the window and double-click ‘PortNumber’.
3.4 Select the ‘Decimal’ option in the Edit DWORD Value’ window.
3.5 Enter the same port number you chose as your new RDP port in Part 1.3 of the guide, then click OK.
Part 4. Testing the changes
4.1 Restart your VPS with the facilities provided in mPanel or from the Shut down menu on the VPS.
4.2 Once mPanel indicates the VPS is back online and responding to pings, double-click the RDP file previously edited in Part 1. of the guide. A security warning dialogue will open. Check the ‘Don’t ask me again for connections to this computer’ box to prevent this popping up each time you want to connect to your VPS, then click Connect.
4.3 The VPS desktop login dialogue should appear if the change was successful. You should notice the port number in use is displayed in the window title. Enter your VPS login credentials and check your VPS’ desktop is as you left it.
4.4 After successfully logging into the VPS using the new RDP port the default RDP firewall rule can be disabled(deselected) and the configuration saved by clicking OK.
4.5 The new configuration can be tested by attempting to connect to the VPS with the original(unmodified) RDP file. Attempting to connect to the VPS with the original RDP file should fail.
Question: To change the default port for all new connections created on the Terminal Server
To change the default port for all new connections created on the Terminal Server
Run Regedit and go to this key:
HKEY_LOCAL_MACHINE’SYSTEM’CurrentControlSet’
Control’Terminal Server’WinStations’RDP-Tcp
Find the “PortNumber” subkey and notice the value of 00000D3D, hex for (3389).
Modify the port number in Hex and save the new value.
You can now connect to the new port by using the “old” Windows 2000 Terminal Server client.
A better option is to use the RDP client found in Windows XP, or even better,the newer Windows Server 2003 SP1 RDP 5.2 client.
You’ll need to configure your TS client to connect to the new port. Although changing the connection port on the RDP clients is quite easy, you CAN also change the connection port for the TS client. See Related Articles list for more info.
In this How-To, we will walk you through changing the RDP Port in Windows Server 2012.
Remote Desktop Protocol (RDP) is a protocol that allows you to connect and control another computer via an existing network making it a remote connection. By default, Windows has assigned port 3389 as the default port to connect. To enable RDP on your Windows Server 2012, you can click here for more information.
Prerequisites
– A Server with Windows Server 2012. If you do not have a server already, why not consider a Windows Cloud Hosting from Atlantic.Net and be up in 30 seconds or less.
Change The RDP Port in Windows 2012
Connect to your server via Remote Desktop
On your keyboard hold down the Windows logo + R buttons which opens the “Run” dialog and execute the “cmd” command and click OK
This is the Run command window in Windows Server 2012
Type “regedit” and click enter
This is the regedit command in Windows Server 2012
This is the registry path to change the RDP Port in Windows 2012
Find the “PortNumber” registry subkey and either right-click or double-click it. A box should pop that says “edit DWORD.” Find the value data (it should say 3389 for standard installations) and change it to the port that you would like. In this example, we chose port 1050.
This is the Port value field in the Windows Server 2012 Registry
Exit the registry editor
IMPORTANT: Before restarting your server, be sure that you have enabled your new RDP port on your Windows firewall. Take a look at our guide if you do not know how to add a custom firewall port “Adding a custom firewall rule.”
Restart your server
To access your server over the new port simply type in your IP followed by :PORT (YOUR.IP.ADD.RESS:PORT / 192.168.10.25:1050)
Congratulations! You have just changed RDP port in Windows Server 2012. Thank you for following along in this How-To, check back with us for any new updates and to learn more about our reliable cloud hostingservices.
Remote Desktop Protocol, the specification used to define the operation of Remote Desktop Service, uses the transmission control protocol port 3389 by default. However, if your business uses Remote Desktop, consider changing the port configuration, as 3389 is a well-known port and is therefore vulnerable to hacking. Changing the RDP port in Windows entails altering the port forwarding settings in Netgear as well, as the router won’t automatically change the default RDP port to the new number.
1.
Press “Start,” type “regedit” or into the search field and press “Enter” to launch the Registry Editor. You may have to press “Yes” if a message comes up warning you of the dangers of changing registry entries.
2.
Double-click the following folders: “HKEY_LOCAL_MACHINE,” “System,” “CurrentControlSet,” “Control,” “TerminalServer” and “WinStations.”
3.
Click “RDP-TCP.” Right-click “PortNumber” from the right pane and choose “Modify” from the context menu.
4.
Click “Decimal” and enter a new port number into the Value Data field. Click “OK,” then close the Registry Editor and restart the workstation.
5.
Open a Web browser, type “192.168.0.1” (without quotes) into the address bar, then press “Enter.” If the browser fails to navigate to the address, try “192.168.1.1” instead.
6.
Type “admin” into the Username field and “password” into the Password field. Click “OK.”
7.
Select “Port Forwarding/Port Triggering” from the left pane, then select the “Port Forwarding” radio button.
8.
Select the RDP entry and click “Edit Service.” Enter the new port number into the Start Port and End Port fields.
9.
Click “Apply” to change the default RDP port on the Netgear router.
By default, Terminal Server, and the Remote Desktop Protocol uses TCP port 3389. It is sometimes useful to change the port not to conflict with other machines on the network.
To change the default port, follow the simple steps below:
2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Terminal Server\WinStations\RDP-Tcp
3. Locate the “PortNumber” subkey and change the value from 00000D3D (hex for 3389) to some other port between 1025 and 65535.
Note: You will also need to configure your RDP/TS client to connect to the same port by specifying the port number with the IP address, as x.x.x.x:nnnn (where x.x.x.x is your RDP IP, and nnnn is the port number)
If firewall is enabled , Please follow the part A first i.e
Open the port in the windows firewall or if any other firewall enabled other than windows, before changing the default port.
or your server will be inaccessible if you follow the part B first!
Question: Change RDP Listen Port
The default TCP port number for RDP is 3389.
This port can be changed using the registry editor:
Start the Registry Editor.
On the left side navigate to the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp
On the right side locate and double-click the value “PortNumber” in order to open the edit window
Select the “Decimal” option, type the new port number and click OK.
Quit Registry Editor and reboot your computer
If you want to connect to XP/VS Server over the internet you will have to set up a port forwarding on your internet router to forward the external ip address/incoming tcp port 3389 (RDP) of your internet router to the internal ip address/tcp port 3389 (RDP) of your internal XP/VS Server computer.
To connect over the internet you would have to enter the external ip address of your internet router which is reachable from the internet into your RDP client.
Your internet router will receive this request when you try to connect with your RDP client over the internet and will forward this request to the internal ip address of your XP/VS Server computer.
Like that you will be able to reach your internal XP/VS Server with an RDP client over the internet.
PC security is comprised of effective firewalls, efficient anti-malware software, WPA and WEP codes as well as several other software-related tweaks and applications. When Remote Desktop is enabled, additional precautions must be taken to minimize the possibility of malware infection and hacking. If the tech at a software company can remotely operate your computer, then so can anybody else with the knowledge and ability. To protect against bots and script kiddies, the RDP Port must be changed.
The remote desktop protocol drives Remote Desktop Services through Port 3389 by default. Any Remote Desktop connections are made through Port 3389. This is the case for every user reading this unless you have already changed the port. Basically, this means that this port is an easy target. By changing the RDP port, security is enhanced because bots and kiddies are designed to target RDP Port 3389. Change the port!
For this to be truly effective, implement a strong account lockout policy. This defends against the use of RDP protocol to obtain the administrator password. If the password is attainable due to the absence of an account lockout policy, then the RDP Port can be found regardless of what it has been changed to.
Changing the default RDP port is achieved through a simple registry hack. Another method is to change the RDP port with a third-party utility. Always set a restore point before making changes to the registry.
The Registry Hack
Run regedit from the start menu to open the Registry Editor. Navigate to HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, Terminal Server, WinStations and RDP_Tcp. Find the PortNumber dword and right-click.
Select Modify. Alter the base to Decimal and enter the new port number with a value between 1025 and 65535, as long as the port is not in use. Click OK.
Question: How To Change The RDP Port (Remote Desktop) In Windows 10, 8.1 And 7
Here’s how to change the Remote Desktop Port (RDP) in Windows 10. This also applies to Windows 8.1 and Windows 7. Here are also the instructions if you are looking to add an additional Remote Desktop Port
By default, the Windows Remote Desktop service will automatically listen to TCP port 3389.
However, it’s perfectly fine to change or alter the default RDP listening port for any reasons that an administrator can think of. For example, to bypass Firewall that only allow web browsing but restrict Remote Desktop connection and others protocols.
In this case, you might need to change the default TCP 3389 to TCP 80 or 443 for the Remote Desktop service running on Vista Ultimate PC at home.
How to change the Remote Desktop listening port on Windows Vista?
This RDP trick is applicable to Remote Desktop service running on Windows Server 2003 and Windows XP as well (and likely working on Windows Server 2008 or later too)!
Open up the Windows Registry Editor and browse to this Registry path:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Locate the PortNumber Registry key on the right-pane, double-click to open, click the Decimal option in the Base section, enter 443 in the text box and click OK (change 443 to the port number of your need). Take note that:
The new TCP port for Remote Desktop service must not currently in used. To confirm the TCP port 443 is free or unused, type netstat -an | find "443"
at the Command Prompt window. If there is no output from the netstat command, meaning that the TCP 443 port number is not in used (and thus available for new RDP listening port).
If you’re not comfortable with Windows Registry Editor, you can simply copy and paste the following Console Registry Tool command (Reg.exe) to an elevated Command Prompt window in Windows Vista: You might need to download Reg.exe from Microsoft if it’s not currently in your Windows. REG ADD “HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v PortNumber /t REG_DWORD /d 443 /f
To change back to the default, simply replace the PortNumber Registry key (in this case, TCP 443) to TCP port 3389.
How to restart Windows Remote Desktop service after changing its listening port?
There are at least two ways to enable/disable or restart Remote Desktop service – Group Policies or System Properties:
Using Group Policies (i.e. gpedit.msc)
Click the Vista Orb, type gpedit.msc in the Start Searchtext box (Vista Instant Search) and double-click the “gpedit” in the Program list
For Windows XP SP2: In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, double-click the Allows users to connect remotely using Terminal Services setting.
In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Terminal Server, Connections, double-click the Allows users to connect remotely using Terminal Services setting.
Click Disable to deactivate Remote Desktop and then click Enable to reactivate the service again.
Using System Properties dialog box
If the “Allows users to connect remotely using Terminal Services” Group Policy setting is set to “Not Configured”, the “Enable Remote Desktop on this computer” setting (on the Remote tab of the System Properties dialog box) takes precedence. Otherwise, the “Allows users to connect remotely using Terminal Services” Group Policy setting takes precedence.
Click the Vista Orb, type system, locate the “System” shortcut in the Program list and double-click to open it
Click the Remote Setting shortcut (require administrative privilege if UAC is turned on) in the Task pane (on the left)
In the Remote Desktop section, select the “Don’t allow connection to this computer” option and click Apply button.
Select either “Allow connections from computers running any version of Remote Desktop (less secure)” or “Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)” option and click Apply button – to reactivate Remote Desktop service to listen on new TCP port number.
Select Properties option from the pop-up context menu
Click on the Remote tab of System Properties dialog box
In the Remote Desktop section, untick the check box that labelled “Allow Users To Connect Remotely To This Computer” and click the Apply button
Tick the check box that labelled “Allow Users To Connect Remotely To This Computer” and click the OK button
Now, the netstat -an | find "443" will showing the TCP 443 port listening for RDP connection!
How to connect to a Windows Remote Desktop service that is not listening on the default TCP 3389 port number?
Open the Remote Desktop Connection client and specify the host:port syntax (e.g. Vista-Ultimate:443) as the connection string.
Instruct the Windows Vista Remote Desktop Connection client to connect to localhost at TCP port 9999 (via SSH Port Forwarding) instead of the default RDP listening port
1. Change registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber from 3389 to your port number
2. Allow your port number within Windows 2008 Firewall (and specify scope of IP addresses that can access the server via RDP – this is optional but good security practice).
3. Restart the RDP service or reboot the server
See pics for details:
Lunch regedit via Start > Run :
Modify PortNumber in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\ from 3389 to your custom number in our case to 1970:
Go to Manage Console:
Disable current Remote Desktop firewall rule:
Create new Rule:
Allow only one or few more IP addresses to connect via Remote Desktop:
It should look like this:
Restart Remote Desktop Service (plus dependent services):
OR you can just reboot the whole server
In regards to security the setup is not security through obscurity but it prevents automated bots from discovering your servers open port and performing brute force password guessing on it. Also if you setup the scope properly with IP addresses or IP ranges the port will not even come up on standard port scan. There is nmap tool (now with GUI) that can sort of deduce the port but it is still useless unless you are expert network penetration expert.
As far as maintaining the information about the change of port I recommend you look into NOC software like Nagios. This will tell other admins about what you have done, what the port number for RDP is and who is allowed to access it.
Changing the listening port for Remote Desktop: Remote Desktop is a very important feature of Windows which allows users to connect to a computer in another location and interact with that computer as if it’s present locally. For example, you are at work and you want to connect to your home PC then you can easily do if RDP is enabled on your home PC. By default, RDP (Remote Desktop Protocol) uses port 3389 and since it’s a common port, every user has information about this port number which can lead to a security risk. So it’s highly recommended to change the listening port for Remote Desktop Connection and to do so follow the below-listed steps.
3.Now make sure you have highlighted RDP-Tcp in the left pane then in the right pane look for the subkey “PortNumber.“
4.Once you have found PortNumber then double-click on it to change its value. Make sure to select Decimal under Base to see the edit its value.
5.You should see the default value (3389) but in order to change it’s value type a new port number between 1025 and 65535, and click OK.
6.Now, whenever you try to connect to you home PC (for which you changed the port number) using Remote Desktop Connection, make sure to type in the new port number.
Note: You may also need to change the firewall configuration in order to allow the new port number before you can connect to this computer using Remote Desktop Connection.
7.To check the result run cmd with administrative rights and type: netstat -a
Add a custom inbound rule to allow the port through the Windows Firewall
1.Press Windows Key + X then select Control Panel.
2.Now navigate to System and Security > Windows Firewall.
3.Select Advanced Settings from the left-hand side menu.
4.Now select Inbound Rules on the left.
5.Go to Action then click on New Rule.
6.Select Port and click Next.
7.Next, select TCP (or UDP) and Specific local ports, and then specify the port number which you want to allow connection for.
8.Select Allow the connection in the next window.
9.Select the options which you need from Domain, Private, Public (private and public are the network types that you select when you connect to the new network, and Windows ask you to select the network type, and the domain is obviously your domain).
10.Finally, write a Name and Description in the window that shows next. Click Finish.
* Click on “Start”>>Go To “Control Panel”>>Click on “Windows Firewall” * Click on “Exceptions” tab . * Click on “Add Port”. * Specify the required details like Name, Port Number and choose TCP.
How Can I Change my Default Remote Desktop Port? Step 1: Login to your Windows VPS RDP Account, Go To “Start Menu” and then type “regedit.exe” (without quota) in search box and then click on regedit.exe result.
Step 2: In Registry Editor(Regedit), Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber 1. On the Edit menu, click Modify, and then click Decimal. 2. Type the new port number, and then click OK. 3. Exit from Registry Editor.
Allow your new custom RDP Port in Windows Firewall
Step 3: As you can see, we changed our default RDP Port from 3389 to 3344 but now we need to add our new custom port in Firewall Inbound TCP Rule.
1. Go to Start Menu, Type “Firewall” and then click on “Windows Firewall with Advanced Security“ 2. In Windows Firewall, Click on “Inbound Rules“(Left Side) and then click on “New Rules” (You can find this option In Right Side)
3. In “New Inbound rule Wizard” Click on “Port Option” and then click on “Next” button.
4. In Protocol and Ports,Select “TCP” and Enter your new RDP Custom Port number in “Specific Local Ports” and then click on “Next” button
5. Again click on “Next” Button
6. Enter Firewall Rule name like “My Custom RDP Port”, Click on “Next” Button and Close Firewall Application and then Restart your VPS.
How can I access my Windows RDP with my New Custom Port? After restarting your VPS, Wait for few minute and then open Remote Desktop Application on your Local PC and If your VPS IP Address is 1.2.3.4 and your new custom RDP Port is 3344 then enter 1.2.3.4:3344 (IP:Port) in Computer Field and then click on “Connect” Option.
Question: How to Change Windows VPS RDP/RDC Port & Allow New Port?
Changing a Default RDP Port to other port is recommended for your VPS Security, My English is good so I will add some images so you can easily understand this.
Only for Windows 2008 R2
Step 1:
How to Change Default RDP Port?
Login to your VPS Via RDP(Because VNC is slow so I recommended you to use RDP) and go to Start Menu and type “regedit.exe” in search box(without quota)
4. TCP is Selected by Default, We just need to enter our new RDP Port in “Specific Local Ports” so enter your new Port 3399(or your new other port) and then click “Next“
(Tip: Do not reboot your VPS without allowing your new port in Firewall otherwise you will be unable to access your RDP until you fix this via VNC/Console)
Thanks.
Question: Change the Remote Desktop Connection port to your Windows Server
Windows servers are remotely accessible with Remote Desktop via the TCP 3389 port (default port). In some situations, as when you wish to obtain a more secure environment, changing the remote access port can be useful. This article explains how to proceed.
Important note: In order to maintain the access to your server after you change the access port, make sure your firewall is properly configured. To be safe, request a KVMIP or a virtual console if you are making the change for a virtual server.
The instructions below apply to machines under Windows Server 2012, 2008 R2, 2008, and 2003. Follow these steps:
Connect to your server via Remote Desktop
Click simultaneously on the Windows logo + R to open the “Run” dialog and execute the “cmd” command
Open the registry editor by typing the “regedit” command
Search for this registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
Double-click or right-click on the “PortNumber” registry subkey, select the decimal base and type the port number of your choice (the default port is 3389, in this example, we selected port 3390). Click on “Ok” to save your selection.
IMPORTANT: Make sure that remote access to your server through the new port is authorized in your Windows firewall before executing the next step.
Exit the registry editor
Restart your server
After the reboot, specify the Remote Desktop port number.
RDP, known as the Remote Desktop Protocol, is a proprietary Microsoft protocol that is responsible for enabling remote desktop connections to a server. This protocol is highly customizable and its configuration can be edited to increase both its security and flexibility through options such as limiting the number of possible concurrent connections or changing the listening port. This second option, modifying the listening port (where new connections communicate with the server) for RDP, is useful as it can enhance your security setup in a very quick and easy way.
In order to modify the listening port for RDP on your Windows 2012 server, we have put together a short guide that will explain the configuration.
Before you proceed, you should note that if you want to change your RDP listening port, you must allow connections to the new port in your Windows Firewall. If you do not do this, you will be locked out of your server. Once you have allowed the new port number in your Windows Firewall and other firewalls on your system, you can continue with the guide.
Begin by opening an administrative session on the Windows 12 RDP server. Click the Start button. In the field that pops up, you will need to enter the following text and execute:
regedit
The command above will open up the Registry Editor utility window. This Microsoft tool is the central point for making tweaks to how your Windows 12 system runs, and is the location of the port number value for RDP.
With the window open, browse to the following view:
Once you have the RDP-Tcp view open, find the PortNumber field. This field contains the value of your current RDP listening port. For our tutorial, we will change it to 9998 as our new listening port. You can select a different port number, but ensure beforehand that your chosen port number is not already in use on the system and, as a security bonus, is not a commonly-used port number. Edit the PortNumber value to your desired port number:
9998
Next, you will need to restart the remote desktop connection service in order for the port number changes to be implemented. This service, known as Remote Desktop Services can be reloaded within Control Panel. Open Control Panel now.
With Control Panel open, navigate to the following views:
System and Security > Administrative tools > Services
In the services list, you will need to find Remote Desktop Services. Right click on it to bring up the option menu, and click on Restart.
While the remote desktop connection service restarts itself, note that any RDP connections currently on will be disconnected. After RDP is running again, you will be able to connect using the new listening port you set.
Conclusion
Congratulations! You have successfully changed the value of the listening port for RDP on your Windows 12 server. If you liked this easy way to enhance your security setup, share it with your friends.
Question: Modify and Change Remote Desktop Listening Port
How to Change the Listening Port for Remote Desktop
Start Registry Editor by clicking on Start -> Run, and type in regedit in the Run text box, and then press Enter or click OK.
Navigate to the following registry branch/subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Locate the registry entry PortNumber in the right pane.
Right click on PortNumber and choose Modify (or select PortNumber, then click on Edit menu and select Modify).
On the Edit DWORD Value window, click on Decimal.
Type in the new port number on the Value Data text box.
Click OK when done.
Question: Changing the Remote Desktop Port
The default port that the Windows Remote Desktop Connection program listens on is 3389. However, you can change to any port you wish; maybe you find public networks block everything except port 80 and 433 (in which you could set it to 433) or you feel changing to a non-default port is better security wise. Whatever your case, you must edit the Windows Registry:
Then if you use the Windows Remote Desktop Connection program to connect to the computer, follow the address you want to connect to with a colon and the port number that you changed to; for example 255.255.255.255:433.
Question: How to change rdp server port 3389 to 80?
You can change the listening port by tweaking the registry.
To change the port that Remote Desktop listens on, follow these steps:
>On the Edit menu, click Modify, and then click Decimal.
>Type the new port number, and then click OK.
The same information is found in MS KB article 306759
Question: Change RDP port on a Windows Server
Windows servers are remotely accessible with Remote Desktop via the TCP 3389 port (default port). In some situations, when a more secure environment is needed, changing the remote access port can be useful. This article explains how to change the RDP port on a Windows Hosting Server.
Note: Make sure you have opened remote access to the new RDP port in Windows Firewall before starting to avoid locking yourself out of the server.
WARNING: Be careful when making changes to the Windows Registry as it contains critical configuration settings for your operating system.
The instructions below apply to machines running Windows Server 2012, 2008 R2, 2008, and 2003. Please follow the below steps to change the RDP port:
1. Connect to the server via Remote Desktop
2. Click simultaneously on the Windows logo + R to open the “Run” dialog
3. Open the registry editor by typing the “regedit” command
4. Search for this registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
5. Double-click or right-click on the “PortNumber” registry subkey, select the decimal base and type the port number of your choice (the default port is 3389, in this example, the selected port is 3312). Click on “OK” to save the selection.
IMPORTANT: Make sure that remote access to your server through the new port is authorized in your Windows firewall before executing the next step.
6. Exit the registry editor
7. Restart your server
After the reboot, specify the Remote Desktop port number.
Question: Virtualization Station: Modify and Change Remote Desktop Listening Port
How to Change the Listening Port for Remote Desktop
Microsoft has a Knowledge Base article KB306759 that details how to modify and change the Remote Desktop listening port by changing registry value.
Start Registry Editor by clicking on Start -> Run, and type in regedit in the Run text box, and then press Enter or click OK.
Navigate to the following registry branch/subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Locate the registry entry PortNumber in the right pane.
Right click on PortNumber and choose Modify (or select PortNumber, then click on Edit menu and select Modify).
On the Edit DWORD Value window, click on Decimal.
Type in the new port number on the Value Data text box.
Kindly remember to open a new port in the Windows Firewall.
(port 3389 TCP, for video; UDP, to stream audio redirection)
How to:
Open Windows Firewall by clicking the Start button , and then clicking Control Panel. In the search box, type firewall, and then click Windows Firewall.
In the left pane, click Advanced settings. If you’re prompted for an administrator password or confirmation, type the password or provide confirmation.
In the Windows Firewall with Advanced Security dialog box, in the left pane, click Inbound Rules, and then, in the right pane, click New Rule.
Follow the instructions in the New Inbound Rule wizard.
You need to do 3 steps to enable and change RDP Port in Windows Server 2008, 2008R2, 2012. You need to do this, if you have more servers at the same IP address, behind a router.
1st step: Enable RDP in System settings. You can go there by right clicking on Computer -> Propreties. Choose Advanced System Settings from the left side menu.
2nd Step: Change RDP Port: Open the registry editor (regedit: open cmd -> regedit.exe). Select HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber . Change to decimal mode, and change the port number, then click ok.
3rd Step: Enable the new Port in the Firewall settings. Open Server Manager, Select Firewall Settings in the left menu, right click on Inbound Rouls -> New. Choose TCP, set Port number, and name it.
Thats all. After this you should restart your server, then everything should work fine. Default port for RDP is 3389 (TCP). Enjoy.
Question: Securing Remote Desktop (RDP) for System Administrators
How secure is Windows Remote Desktop?
Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP. This vulnerability can allow unauthorized access to your session using a man-in-the-middle attack(link is external). Remote Desktop can be secured using SSL/TLS in Windows Vista, Windows 7, and Windows Server 2003/2008.
While Remote Desktop is more secure than remote administration tools such as VNC that do not encrypt the entire session, any time Administrator access to a system is granted remotely there are risks. The following tips will help to secure Remote Desktop access to both desktops and server that you support.
Basic Security Tips for Remote Desktop
Use strong passwords
Use a strong password on any accounts with access to Remote Desktop. This should be considered a required step before enabling Remote Desktop. Refer to the campus password complexity guidelines for tips.
Update your software
One advantage of using Remote Desktop rather than 3rd party remote admin tools is that components are automatically updated to the latest security fixes in the standard Microsoft patch cycle. Make sure your are running the latest versions of both the client and server software by enabling and auditing automatic Microsoft Updates. If you are using Remote Desktop clients on other platforms, make sure they are still supported and that you have the latest versions. Older versions may not support high encryption and may have other security flaws.
Restrict access using firewalls
Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389). Using an RDP Gateway is highly recommended for restricting RDP access to desktops and servers (see discussion below). As an alternative to support off-campus connectivity, you can use the campus VPN software to get a campus IP address, and add the campus VPN network address pool to your RDP firewall exception rule. See http://net.berkeley.edu/vpn/(link is external) for more information on the campus VPN service.
Enable Network Level Authentication
Windows Vista, Windows 7, and Windows Server 2008 also provide Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don’t support it.
Enabling NLA on Windows 2012 Server, Windows 8, and Windows 10:
NLA should be enabled by default on Windows 2012 Server, Windows 8, and Windows 10.
To check you may look at Group Policy setting Require user authentication for remote connections by using Network Level Authentication found at Computer\Policies\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. This Group Policy setting must be enabled on the server running the Remote Desktop Session Host role.
Limit users who can log in using Remote Desktop
By default, all Administrators can log in to Remote Desktop. If you have multiple Administrator accounts on your computer, you should limit remote access only to those accounts that need it. If Remote Desktop is not used for system administration, remove all administrative access via RDP and only allow user accounts requiring RDP service. For Departments that manage many machines remotely, remove the local Administrator account from RDP access at and add a technical group instead.
Under Local Policies–>User Rights Assignment, go to “Allow logon through Terminal Services.” Or “Allow logon through Remote Desktop Services”
Remove the Administrators group and leave the Remote Desktop Users group.
Use the System control panel to add users to the Remote Desktop Users group.
A typical MS operating system will have the following setting by default as seen in the Local Security Policy:
The problem is that “Administrators” is here by default, and your “Local Admin” account is in administrators. Although a password convention to avoid identical local admin passwords on the local machine and tightly controlling access to these passwords or conventions is recommended, using a local admin account to work on a machine remotely does not properly log and identify the user using the system. It is best to override the local security policy with a Group Policy Setting.
To control access to the systems even more, using “Restricted Groups” via Group Policy is also helpful.
If you use a “Restricted Group” setting to place your group e.g. “CAMPUS\LAW-TECHIES” into “Administrators” and “Remote Desktop Users”, your techies will still have administrative access remotely, but using the steps above, you have removed the problematic “local administrator account” having RDP access. Going forward, whenever new machines are added in the OU under the GPO, your settings will be correct.
Set an account lockout policy
By setting your computer to lock an account for a period of time after a number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a “brute-force” attack). To set an account lockout policy:
Go to Start–>Programs–>Administrative Tools–>Local Security Policy
Under Account Policies–>Account Lockout Policies, set values for all three options. 3 invalid attempts with 3 minute lockout durations are reasonable choices.
Best Practices for Additional Security
Change the listening port for Remote Desktop
Changing the listening port will help to “hide” Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers effective protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Change the listening port from 3389 to something else and remember to update any firewall rules with the new port. Although this approach is helpful, it is security by obscurity which is not the most reliable security approach. You should ensure that you are also using other methods to tighten down access as described in this article.
Use RDP Gateways
Using a RDP Gateway is strongly recommended. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single “Gateway” server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443), and connects the client to the Remote Desktop service on the target machine.
Installing the configuring the role service is mostly as described; however, using a Calnet issued trusted Comodo certificate is recommended. Using a self-signed cert is ok for testing, and using a CalnetPKI cert can work if all clients have trusted the UCB root. The Comodo cert is usually better accepted so that your end users do not receive certificate warnings.
Some campus units use a IST managed VPS as a RD Gateway, and a VPS seems fine for this purpose. A rough estimate might be that 30-100 concurrent users can use one RD Gateway. The HA at the virtual layer provides enough fault tolerant and reliable access, however a slightly more sophisticated RD gateway implementation can be done with network load balancing.
In essence, a simple change on the advance tab of your RDP client is all that is necessary:
Tunnel Remote Desktop connections through IPSec or SSH
If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems since Windows 2000, but use and management is greatly improved in Windows Vista/7/2008 (see: http://technet.microsoft.com/en-us/network/bb531150(link is external)). If an SSH server is available, you can use SSH tunneling for Remote Desktop connections. See https://kb.berkeley.edu/kb1266(link is external) for more information on IPSec and SSH tunneling.
Use existing management tools for RDP logging and configuration
Using other components like VNC or PCAnywhere are not recommended because they may not log in a fashion that is auditable or protected. With RDP, logins are audited to the local security log, and often to the domain controller auditing system. When monitoring local security logs, look for anomalies in RDP sessions such as login attempts from the local Administrator account. RDP also has the benefit of a central management approach via GPO as described above. Whenever possible, use GPOs or other Windows configuration management tools to ensure a consistent and secure RDP configuration across all your servers and desktops.
By enforcing the use of a RDP gateway, you also get a third level of auditing that is easier to read than combing through the domain controller logins, and is separate from the target machine so is not subject to tampering. This type of log can make it much easier to monitor how and when RDP is being used across all the machines in your environment.
Use Two-factor authentication on highly sensitive systems
Departments with sensitive data should also consider using a two-factor authentication approach. That is beyond the scope of this article, but RD Gateways do provide a simple mechanism for controlling authentication via two factor certificate based smartcards. Other two factor approaches need another approach at the Remote Desktop host itself e.g. YubiKey, RSA.
Additional security with Network Access Protection (NAP)
Highly motivated admins can also investigate the use Network Access Protection(NAP) with an RD Gateway, however, that technology and standard is not well developed or reliable yet. Many clients will not work if you enforce it, although by following the documentation, you can audit the system to see if it *thinks* the clients are security compliant.
In this tutorial i will explain how to change the Remote Desktop Protocol (RDP) port number using the registry editor (regedit).
I tested this procedure on :
– Windows Server 2003
– Windows XP
– Windows Vista
– Windows 7
– Windows 8
– Windows Server 2008
– Windows Server 2012
By default the Remote Desktop Protocol and Terminal Server listens on TCP port 3389, to change that port number for all new connections :
1 – Start -> Run… type ‘regedit.exe‘ then press OK
2 – Browse to this key : HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > RDP-Tcp
3 – Find the ‘PortNumber‘ subkey, clic modify, choose decimal and change it’s value and finally save.
Note : The default value is “00000D3D” HEX for the decimal value “3389“.
4 – Make sure that the new configured port in open on the firewall.
5 – Restart the computer.
That’s all, now you’ll need to configure your TS client to connect to the new port.
Remember that it is important to change that port number to be protected against piracy and robots that try to get in by sending different passwords ‘with the root and administrator usernames’ on that ‘default’ port 3389.
Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, which provides a user with a graphical interface to connect to another computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software.
Every version of Microsoft Windows from Windows XP onwards[4] includes an installed Remote Desktop Connection (RDC) (“Terminal Services”) client (mstsc.exe) whose version is determined by that of the operating system or by the last applied Windows Service Pack. The Terminal Services server is supported as an official feature on Windows NT 4.0 Terminal Server Edition, Windows 2000 Server, all editions of Windows XP except Windows XP Home Edition, Windows Server 2003, Windows Home Server, on Windows Fundamentals for Legacy PCs, in Windows Vista Ultimate, Enterprise and Business editions, Windows Server 2008 and Windows Server 2008 R2 and on Windows 7 Professional and above.[citation needed]
Microsoft provides the client required for connecting to newer RDP versions for downlevel operating systems. Since the server improvements are not available downlevel, the features introduced with each newer RDP version only work on downlevel operating systems when connecting to a higher version RDP server from these older operating systems, and not when using the RDP server in the older operating system.[clarification needed]
Based on the ITU-T T.128 application sharing protocol (during draft also known as “T.share”) from the T.120 recommendation series, the first version of RDP (named version 4.0) was introduced by Microsoft with “Terminal Services”, as a part of their product Windows NT 4.0 Server, Terminal Server Edition. The Terminal Services Edition of NT 4.0 relied on Citrix‘s MultiWin technology, previously provided as a part of Citrix WinFrame atop Windows NT 3.51, in order to support multiple users and login sessions simultaneously. Microsoft required Citrix to license their MultiWin technology to Microsoft in order to be allowed to continue offering their own terminal-services product, then named Citrix MetaFrame, atop Windows NT 4.0. The Citrix-provided DLLs included in Windows NT 4.0 Terminal Services Edition still carry a Citrix copyright rather than a Microsoft copyright. Later versions of Windows integrated the necessary support directly. The T.128 application sharing technology was acquired by Microsoft from UK software developer Data Connection Limited.[5][6]
This version was introduced with Windows 2000 Server, added support for a number of features, including printing to local printers, and aimed to improve network bandwidth usage.
This version was introduced with Windows XP Professional and included support for 24-bit color and sound. The client is available for Windows 2000, Windows 9x, Windows NT 4.0.[7] With this version, the name of the client was changed from Terminal Services Client to Remote Desktop Connection; the heritage remains to this day, however, as the underlying executable is still named mstsc.exe.
This version was introduced with Windows Server 2003, included support for console mode connections, a session directory, and local resource mapping. It also introduces Transport Layer Security (TLS) 1.0 for server authentication, and to encrypt terminal server communications.[8] This version is built into Windows XP Professional x64 Edition and Windows Server 2003 x64 & x86 Editions.
This version was introduced with Windows Vista and incorporated support for Windows Presentation Foundation applications, Network Level Authentication, multi-monitor spanning and large desktop support, and TLS 1.0 connections.[9] Version 6.0 client is available for Windows XP SP2, Windows Server 2003 SP1/SP2 (x86 and x64 editions) and Windows XP Professional x64 Edition. Microsoft Remote Desktop Connection Client for Macintosh OS X is also available with support for Intel and PowerPC Mac OS versions 10.4.9 and greater.
This version was released in February 2008 and is included with Windows Server 2008, as well as with Windows Vista Service Pack 1. The client is included with Windows XP SP3.[10] In addition to changes related to how a remote administrator connects to the “console”,[11] this version has new functionality introduced in Windows Server 2008, such as connecting remotely to individual programs and a new client-side printer redirection system that makes the client’s print capabilities available to applications running on the server, without having to install print drivers on the server.[12][13]
This version was released to manufacturing in July 2009 and is included with Windows Server 2008 R2, as well as with Windows 7.[14] With this release, also changed from Terminal Services to Remote Desktop Services. This version has new functions such as Windows Media Player redirection, bidirectional audio, multi-monitor support, Aero glass support, enhanced bitmap acceleration, Easy Print redirection,[15]Language Bar docking. The RDP 7.0 client is available on Windows XP SP3 and Windows Vista SP1/SP2 through KB969084.[16] RDP 6.1 client and RDP 7.0 client are not supported on Windows Server 2003 x86 and Windows Server 2003 / Windows XP Professional x64 editions. RDP 7.0 is also not supported on Windows Server 2008. RDP 7.0 clients also do not support connecting to terminal servers running Windows 2000 Server.[17]
Most RDP 7.0 features like Aero glass remote use, bidirectional audio, Windows Media Player redirection, multiple monitor support and Remote Desktop Easy Print are only available in Windows 7 Enterprise or Ultimate editions.[18][19]
SP1 and Server 2008 R2 SP1. It adds RemoteFX functionality.
This version was released in Windows 8 and Windows Server 2012. This version has new functions such as Adaptive Graphics (progressive rendering and related techniques), automatic selection of TCP or UDP as transport protocol, multi touch support, DirectX 11 support for vGPU, USB redirection supported independently of vGPU support, etc.[20][21] A “connection quality” button is displayed in the RDP client connection bar for RDP 8.0 connections; clicking on it provides further information about connection, including whether UDP is in use or not.[22]
The RDP 8.0 client and server components are also available as an add-on for Windows 7 SP1. The RDP 8.0 client is also available for Windows Server 2008 R2 SP1, but the server components are not. The add-on requires the DTLS protocol to be installed as prerequisite.[22] After installing the updates, for the RDP 8.0 protocol to be enabled between Windows 7 machines, an extra configuration step is needed using the Group Policy editor.[23]
A new feature in RDP 8.0 is limited support for RDP session nesting; it only works for Windows 8 and Server 2012 though, Windows 7 and Server 2008 R2 (even with the RDP 8.0 update) do not support this feature.[24]
The “shadow” feature from RDP 7, which allowed an administrator to monitor (snoop) on a RDP connection has been removed in RDP 8. The Aero Glass remoting feature (applicable to Windows 7 machines connecting to each other) has also been removed in RDP 8.[21][22]
This version was released with Windows 8.1 and Windows Server 2012 R2. A RDP 8.1 client update exists for Windows 7 SP1 as well, but unlike the RDP 8.0 update for Windows 7, it does not add a RDP 8.1 server component to Windows 7. Furthermore, if RDP 8.0 server function is desired on Windows 7, the KB 2592687 (RDP 8.0 client and server components) update must be installed before installing the RDP 8.1 update.[25][26]
Support for session shadowing was added back in RDP version 8.1. This version also fixes some visual glitches with Microsoft Office 2013 when running as a RemoteApp.[25]
Version 8.1 of the RDP also enables a “restricted admin” mode. Logging into this mode only requires knowledge of the hashed password, rather than of its plaintext, therefore making a pass the hash attack possible.[27] Microsoft has released an 82-page document explaining how to mitigate this type of attack.[28]
Version 10.0 of the RDP includes the following new features: AutoSize zoom (useful for HiDPI clients).[29] In addition graphics compression improvements were included utilizing H.264/AVC.[30]
32-bit color support. 8-, 15-, 16-, and 24-bit color are also supported.
128-bit encryption, using the RC4 encryption algorithm, as of Version 6.[31]
Audio Redirection allows users to process audio on a remote desktop and have the sound redirected to their local computer.
File System Redirection allows users to use their local files on a remote desktop within the terminal session.
Printer Redirection allows users to use their local printer within the terminal session as they would with a locally- or network-shared printer.
Port Redirection allows applications running within the terminal session to access local serial and parallel ports directly.
The remote computer and the local computer can share the clipboard.
Microsoft introduced the following features with the release of RDP 6.0 in 2006:
Seamless Windows: remote applications can run on a client machine that is served by a Remote Desktop connection. It is available since RDP 6.[32]
Remote Programs: application publishing with client-side file-type associations.
Terminal Services Gateway: enables the ability to use a front-end IIS server to accept connections (over port 443) for back-end Terminal Services servers via an https connection, similar to how RPC over https allows Outlook clients to connect to a back-end Exchange 2003 server. Requires Windows Server 2008.
Support for Transport Layer Security (TLS) 1.0 on both server and client ends (can be negotiated if both parties agree, but not mandatory in a default configuration of any version of Windows).
Multiple monitor support for allowing one session to use multiple monitors on the client (disables desktop composition)
Release 7.1 of RDP in 2010 introduced the following feature:
RemoteFX: RemoteFX provides virtualized GPU support and host-side encoding; it ships as part of Windows Server 2008 R2 SP1.
RDP sessions are also susceptible to in-memory credential harvesting, which can be used to launch pass the hash attacks.[citation needed]
In March 2012, Microsoft released an update for a critical security vulnerability in the RDP. The vulnerability allowed a Windows computer to be compromised by unauthenticated clients and computer worms.[35]
RDP client version 6.1 can be used to reveal the names and pictures of all users on the RDP Server (no matter which Windows version) in order to pick one, if no username is specified for the RDP connection.[citation needed]
In March 2018 Microsoft released a patch for CVE-2018-0886, a remote code execution vulnerability in CredSSP, which is a Security Support Provider involved in the Microsoft Remote Desktop and Windows Remote Management, discovered by Preempt.[36][37]
There are numerous non-Microsoft implementations of RDP clients and servers that implement subsets of the Microsoft functionality. For instance, the open-source command-line client rdesktopis available for Linux/Unix and Microsoft Windows operating systems. There are many GUI clients, like tsclient and KRDC, that are built on top of rdesktop; CoRD is such a client for the Macintosh.
In 2009, rdesktop was forked as FreeRDP, a new project aiming at modularizing the code, addressing various issues, and implementing new features.[38] FreeRDP comes with its own command-line-client xfreerdp, which supports Seamless Windows in RDP6. There’s also a GTK-Application named Remmina.
An open-source implementation of a Remote Desktop Protocol server on Unix is FreeRDP and xrdp. The Windows’ Remote Desktop Connection client can be used to connect to a server. Proprietary RDP client solutions such as rdpclient are available as a stand-alone application or embedded with client hardware.
A new access paradigm, browser-based access, has enabled users to access Windows desktops and applications on any RDP hosts, such as Microsoft Remote Desktop (RDS) Session Hosts (Terminal Services) and virtual desktops, as well as remote physical PCs.
There is also a so-called VRDP used in the VirtualBox virtual machine implementation by Oracle. This protocol is compatible with all RDP clients, such as that provided with Windows but, unlike the original RDP, can be configured to accept unencrypted and password unprotected connections, which may be useful in secure and trusted networks, such as home or office LANs. By default, Microsoft’s RDP server refuses connections to user accounts with empty passwords (but this can be changed with the Group Policy Editor[39]). External and guest authorization options are provided by VRDP as well. It does not matter which operating system is installed as a guest because VRDP is implemented on the virtual machine (host) level, not in the guest system. The proprietary VirtualBox Extension Pack is required.
Microsoft requires third-party implementations to license the relevant RDP patents.[40] As of February 2014, the extent to which open-source clients meet this requirement remains unknown.
Make sure any local and/or public firewalls are configured appropriately. Restart the system.
Optional: Security Layers and Encryption Levels, NLA
There are three security layer options available for RDP:
RDP Security Layer – communication between the server and the client will use native RDP encryption.
Negotiable – The most secure layer that is supported by the client will be used.
SSL (TLS 1.0) – SSL will be used for server authentication and for encryption all data transferred between the server and the client.
There are four encryption level options for RDP:
Low.
Client Compatible (the one enabled by default) – all data sent between the client and the server is protected by encryption based on the maximum key strength supported by the client.
High – all data sent between the client and the server is protected by encryption based on the server’s maximum key strength.
FIPS Compliant – all data sent between the client and the server is protected by using FIPS 140-1 validated encryption methods. FIPS is US Federal Information Processing Standard, not a protocol.
Network Level Authentication (NLA) is also available for Remote Desktop Connection 6.0 and above.
To change remote desktop security level to high (TLS), do:
Identify recently created user accounts that have not been used to access a web service in 14 days. I’m looking to filter on accounts with a blank LastLogonTimeStamp, and a whenCreated date of -14 days:
![[IMG]](https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Fmilkytech.com%2Fimages%2Fregedit.jpg&container=blogger&gadget=a&rewriteMime=image%2F*)
SomaBright 
