Windows Terminal Download ~UPD~ Windows Server 2019
Keiko Middlekauff
Although nano also exists as choco package, it is very outdated. Instead manually install this nano. However, when using over SSH, nano control characters get a bit confused, so you may lose some, since windows use it's own API for controlling screen characters, and not POSIX. So although a lot of work is currently in progress for future Win10 compatibility.
i am not able to find any good documentation if unattended desktop flows can run on windows server (e. g. windows server 2019 standard) if any other user is logged on that machine (not that user that is used in Power Automate to execute the flow).
On a windows server that acts as terminal server using using RDS (Remote Desktop Services) it is very unlikely that all users are signed off (that is the nature of a terminal server to provide a virtual desktop for centralized applications used by several users concurrently)..
#### Scenario 1 - Win 2019, no RDS, one unattended flow, one human session
- without RDS server will accept a maximum of 2 concurrent RDP sessions
- you can have one user logged in with, let's say "Developer Account" windows/domain account
- at the same time, you can execute one unattended flow using the "Unattended Service Account" windows/domain account
- no particular configuration is needed here; ensure your flow uses a desktop connection set up with a dedicated user account, different from the other user(real person) logging into the server,
- if more unattended flows are scheduled to run at the same time, they will be queued in the machine queue
#### Scenario 2 - Win 2019, no RDS, two unattended flow
- If you want two unattended flows run on such a machine, you need two unattended add-ons, and then no 3rd session can be connected (as a Win will not accept 3rd connection), and the unattended flows need to be using DIFFERENT windows/domain accounts for their session.
#### Scenario 3 - Win 2019, with RDS, multiple unattended flows and "human" sessions
- You can have a virtually unlimited number of unattended flows, but you need an RDS license for each session and enough resources.
- Ensure each unattended flow is executed using different windows/user accounts - like in scenario 1
- Ensure you have the required number of unattended addon-s; if you want five unattended flows at the same time - you need five add-ons
If you have three add-ons, three unattended flows will be able to run at the same time, and the rest will be queued
- in this scenario, you might be required to install a gateway (I did not check the docs for some time, but I think it is still needed)
- So, in this scenario, you can have any number of unattended flows and people logged in, but you need to have RDS licenses for each session, an unattended add-on for each unattended flow and each of the sessions needs to be using a dedicated domain/windows account
and i meant "Unattended" for a user that is not logged in on that terminal server (you configure the user in your cloud flow that triggers the "unattended" flow) but what happens if other users are logged on that machine. the docu says that all users need to be logged off.
@OkanAT thanks a lot for your answer.. it seems that "unattended" flows on Windows Servers that are used as terminal server (RDS) are not a good idea as terminal servers usually have a lot of concurrent users logged in (this is the nature of a terminal server)..
The key server component of RDS is Terminal Server (termdd.sys), which listens on TCP port 3389. When a Remote Desktop Protocol (RDP) client connects to this port, it is tagged with a unique SessionID and associated with a freshly spawned console session (Session 0, keyboard, mouse and character mode UI only). The login subsystem (winlogon.exe) and the GDI graphics subsystem is then initiated, which handles the job of authenticating the user and presenting the GUI. These executables are loaded in a new session, rather than the console session. When creating the new session, the graphics and keyboard/mouse device drivers are replaced with RDP-specific drivers: RdpDD.sys and RdpWD.sys. The RdpDD.sys is the device driver and it captures the UI rendering calls into a format that is transmittable over RDP. RdpWD.sys acts as keyboard and mouse driver; it receives keyboard and mouse input over the TCP connection and presents them as keyboard or mouse inputs. It also allows creation of virtual channels, which allow other devices, such as disc, audio, printers, and COM ports to be redirected, i.e., the channels act as replacement for these devices. The channels connect to the client over the TCP connection; as the channels are accessed for data, the client is informed of the request, which is then transferred over the TCP connection to the application. This entire procedure is done by the terminal server and the client, with the RDP mediating the correct transfer, and is entirely transparent to the applications.[13] RDP communications are encrypted using 128-bit RC4 encryption. Windows Server 2003 onwards, it can use a FIPS 140 compliant encryption schemes.[6]
Once a client initiates a connection and is informed of a successful invocation of the terminal services stack at the server, it loads up the device as well as the keyboard/mouse drivers. The UI data received over RDP is decoded and rendered as UI, whereas the keyboard and mouse inputs to the Window hosting the UI is intercepted by the drivers, and transmitted over RDP to the server. It also creates the other virtual channels and sets up the redirection. RDP communication can be encrypted; using either low, medium or high encryption. With low encryption, user input (outgoing data) is encrypted using a weak (40-bit RC4) cipher. With medium encryption, UI packets (incoming data) are encrypted using this weak cipher as well. The setting "High encryption (Non-export)" uses 128-bit RC4 encryption and "High encryption (Export)" uses 40-bit RC4 encryption.[14]
Terminal Server is the server component of Terminal services. It handles the job of authenticating clients, as well as making the applications available remotely. It is also entrusted with the job of restricting the clients according to the level of access they have. The Terminal Server respects the configured software restriction policies, so as to restrict the availability of certain software to only a certain group of users. The remote session information is stored in specialized directories, called Session Directory which is stored at the server. Session directories are used to store state information about a session, and can be used to resume interrupted sessions. The terminal server also has to manage these directories. Terminal Servers can be used in a cluster as well.[6]
In Windows Server 2008, it has been significantly overhauled. While logging in, if the user logged on to the local system using a Windows Server Domain account, the credentials from the same sign-on can be used to authenticate the remote session. However, this requires Windows Server 2008 to be the terminal server OS, while the client OS is limited to Windows Server 2008, Windows Vista and Windows 7. In addition, the terminal server may be configured to allow connection to individual programs, rather than the entire desktop, by means of a feature named RemoteApp. Terminal Services Web Access (TS Web Access) makes a RemoteApp session invocable from the web browser. It includes the TS Web Access Web Part control which maintains the list of RemoteApps deployed on the server and keeps the list up to date. Terminal Server can also integrate with Windows System Resource Manager to throttle resource usage of remote applications.[4]
RemoteApp (or TS RemoteApp) is a special mode of RDS, available in Windows Server 2008 R2 and later, where remote session configuration is integrated into the client operating system. The RDP 6.1 client ships with Windows XP SP3, KB952155 for Windows XP SP2 users,[23] Windows Vista SP1 and Windows Server 2008. The UI for the RemoteApp is rendered in a window over the local desktop, and is managed like any other window for local applications. The end result of this is that remote applications behave largely like local applications. The task of establishing the remote session, as well as redirecting local resources to the remote application, is transparent to the end user.[24] Multiple applications can be started in a single RemoteApp session, each with their own windows.[25]
df19127ead