Users "Status" fields blank on RDS with Windows Server 2025
Hi, we have two RDS Server with Windows Server 2025 installed (In-Place Upgrade from Server 2019). In Task-Manager under the "Users" Tab all fields of the "Status" row are blank. We cant see if a user is connected or disconnected. In cmd with "query user" it works. Someone else discovered this problem?
Maximum number of concurrent shells for the Remote Desktop Services plug-in has been exceeded
Server 2019 Standard (2 each) When opening Server Manager, it takes quite awhile to read the RDS servers and eventually comes back for the local server with the error: Maximum number of concurrent shells for the Remote Desktop Services plug-in has been exceeded. Restart Server Manager, and then try again. I have increased the MaxConcurrentUsers to 2147483647, as well as the MaxShellsPerUser just to make sure: On a Server 2012 R2 server, I have both of the 2019 servers in the server list and open the RDS portion of server mgr and do NOT get this error. It ONLY happens when opening RDS in Server Mgr on the 2019 servers. I have scoured all over the Inter-webs for an answer to no avail. Anyone have a fix for this?
Windows Server 2025 Terminal Servers - start menu pinned icons
I'm designing the config for some terminal servers running Server 2025. I want to pin specific icons to the start menu. In Server 2022 (or Windows 10), this was simply a process of setting up the reference machine how I wanted it, then Export-StartLayout -Path "C:\Export\MStartMenuLayout.xml" to generate the config file, whcih was then applied using the GPO Computer Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Start Layout - this worked fine. On Server 2025 (and Windows 11), however, it appears that this doesn't work the same any more. Although the export command works, it generates a JSON file now rather than an XML. OK, so I saved the file with the JSON extension, and copied the old GPO, amending the name of the config file to point to the new one. However, it still doesn't work and this documentation: https://learn.microsoft.com/en-us/windows/configuration/start/layout?tabs=intune-10%2Cintune-11&pivots=windows-11 Would appear to indicate that it can only be done using Intune. If it was Windows 11 I could do that, but as this is Server 2025 it isn't an option - Intune cannot manage server OSs even if I wanted to do that. Can anyone suggest any alternative methods of doing this? All I want to do is configure a common set of pinned apps for all users - I'm not bothered about configuring any other aspects of the start menu as the defaults are OK. ThanksRDS Farm with FIDO2 Key
Hello everyone, I'm trying to install an RDS farm with fido2 (Yubikey). I think I have created the conditions. The farm is onPrem (hybrid joined), the FIDO2 key is registered in Entra. The farm works correctly with normal credentials. However, setting up the FIDO2 key is giving me a headache. If I log in directly to one of the session hosts, FIDO2 works. But if I want to log in via the session broker, as it should be. I am connected to the session broker as a host and not forwarded to the hosts. But I only found this out by chance when I added the user to the Remodesktopuser group on the broker as a test. Otherwise you just get the message: "Access to the session was denied" and the broker's event log says "Couldn't find the file" #################### redirectclipboard:i:1 redirectprinters:i:0 redirectcomports:i:1 redirectsmartcards:i:1 devicestoredirect:s:* drivestoredirect:s: session bpp:i:32 prompt for credentials on client:i:1 server port:i:3389 allow font smoothing:i:1 promptcredentialonce:i:1 gatewayusagemethod:i:2 gatewayprofileusagemethod:i:1 gatewaycredentialssource:i:4 full address:s:RDS-TEST-BR.xxxxxxxxxxxxx gatewayhostname:s:rds-test.xxxxxxxxxxxxx workspace id:s:RDS-Test-BR.xxxxxxxxxxxxx use redirection server name:i:1 loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Test use multimon:i:1 alternate full address:s:RDS-TEST-BR.xxxxxxxxxxxxx screen mode id:i:2 desktopwidth:i:800 desktopheight:i:600 winposstr:s:0,3,0,0,800,600 compression:i:1 keyboardhook:i:2 audiocapturemode:i:0 videoplaybackmode:i:1 connection type:i:7 networkautodetect:i:1 bandwidthautodetect:i:1 displayconnectionbar:i:1 enableworkspacereconnect:i:0 disable wallpaper:i:0 allow desktop composition:i:0 disable full window drag:i:1 disable menu anims:i:1 disable themes:i:0 disable cursor setting:i:0 bitmapcachepersistenable:i:1 audiomode:i:0 redirectlocation:i:0 redirectwebauthn:i:1 redirectposdevices:i:0 autoreconnection enabled:i:1 authentication level:i:2 prompt for credentials:i:0 negotiate security layer:i:1 remoteapplicationmode:i:0 alternate shell:s: shell working directory:s: gatewaybrokeringtype:i:0 rdgiskdcproxy:i:0 kdcproxyname:s: enablerdsaadauth:i:1 username:s:yubikey@xxxxxxxxxxxxx ####################Login failure from tssdis.exe on RDS server
Remote desktop server in AD environment [Windows Server 2019 standard, running RDweb, RDG, and session host, etc] periodically has service tssdis.exe (remote desktop session broker) failing to login, Event IDs 4648 and then 4625 about half a dozen times before stopping. This doesn't appear to affect any users, but I can't find anything online addressing it or if it's something that needs to be fixed. Some other people have reported the problem but not the solution, such as here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/26e48e81-1400-4f8c-aef2-df03143fa211/login-through-tssdisexe Below are two exports of the event IDs (sanitized) This is the 4648 A logon was attempted using explicit credentials. Subject: Security ID: NETWORK SERVICE Account Name: SERVERNAME$ Account Domain: DOMAIN Logon ID: 0x3E4 Logon GUID: {10b9db0d-f9e0-e3ab-8c95-7dcb4ec5b3c7} Account Whose Credentials Were Used: Account Name: SERVERNAME Account Domain: DOMAIN Logon GUID: {00000000-0000-0000-0000-000000000000} Target Server: Target Server Name: SERVERNAME.DOMAIN.local Additional Information: SERVERNAME.DOMAIN.local Process Information: Process ID: 0x17c8 Process Name: C:\Windows\System32\tssdis.exe Network Information: Network Address: fe80::xxxx:f30a:xxxx:xxxx Port: 49667 This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command. This is the 4625: An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: SERVERNAME Account Domain: DOMAIN Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC0000064 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: SERVERNAME Source Network Address: fe80::xxxx:f30a:xxxx:xxxx Source Port: 50798 Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.Windows Server 2019: Remote Desktop Service - Role Servisleri (tr-TR)
Windows Server 2008 ile hayatımıza giren terminal server kavramı Windows Server 2012 ile gelişerek yerini RDS rolüne bıraktı. RDS rolünün bugün geldiği son nokta doğrultusunda Windows Server 2019 RDS mimarisinin 6 alt rolü bulunmaktadır. Remote Desktop Session Host (RDSH): RDSH aslında hepimizin yakından tanıdığı terminal server yapısıdır. Sunucunuz üzerinde bulunan uygulamalara kullanıcılarınızın aynı anda erişimini sağlayarak onların işlem yapmalarını sağladığınız Windows Server rolüdür. Windows Server connection uygulaması ile kullanıcılarınızı Remote Desktop Protokolü (RDP) TCP 3389 varsayılan portunu kullanarak sunucunuza erişimini sağlayabilirsiniz. Domain ve workgroup olarak çalışabilen bu role sayesinde yapınızda DC var ise kullanıcılarınızı yetkilendirerek yada workgroup kullanıyorsanız Local user üzerinden kullanıcılarınızı oluşturarak bu role kullanabilirsiniz. Türkiye de genel olarak kullanım amacı muhasebe yada crm uygulamalarına erişim için tercih edilen roledür. Danışmanlık verdiğim firmalara özelikle önerdiğim hem güvenlik, hem de erişim kolaylığı sağlayan her mimariye yerleştirilebilen Windows Server rolüdür. Web server, DB server yada uygulama serverlarına doğrudan dışarıdan erişim yerine RDSH role tanımlı bir sunucu üzerinden tek IP izni ile erişim yapılabilecek şekilde kurgulanan mimarilerde güvenlik seviyesini en üst seviyede tutarak çalışmalarınızın kararlığını ve sürekliliğini sağlamanızı hedefleyebilirsiniz. Remote Desktop Connection Broker (RDCB): RDS rolünün yönetim servisi olarak düşünebilirsiniz. RDS farm yapısı kullanıyorsanız doğrudan RDSH bağlanmak yerine RDCB sunucusuna bağlantı sağlanır. RDCB sizi hangi RDSH sunucusunda da oturum açacağını yük dengelemesini inceleyerek karar verir bağlantınızı sağlar. Broker kelimesinden benim aklıma her zaman ekonomi brokerları gelir onlar sizin için çalışır ve paranızı nasıl en kazançlı duruma getirir karar verir. RDCB de sizin session istekleriniz doğrultusunda en performanslı sunucuya yönlendirerek işlemlerinizi daha stabil yapmanızı sağlıyor. RDVH rolünü aşağıda detaylı anlatacağım ancak RDHV üzerinde kurguladığınız sanal sunucu mimariniz de bulunan sunucularınıza erişimlerinizi de yine RDCB rolü kontrol ve yönetim işlemini üstlenir. Remote Desktop Web Access (RDWA): Adından da anlaşıldığı üzere uzak bağlantılarınızı web arayüzünden erişim sağlamanıza yarayan RDS rolüdür. RDSH sunucularınızda çalıştırdığınız uygulamalara RDWA rolü üzerinden erişim sağlayabilirsiniz. Remote Desktop Gateway (RDG): Networkunuzda bulunan RDP trafiğini HTTPS protokolü üzerine yönlendiren bir web servistir. Bu role temel amacı aslında 3389 portuna gelen trafik için güvenlik duvarından bu portu açmak yerine 443 SSL portunu açarak trafiğin şifrelenerek, güvenli bir şekilde akışını sağlayabilirsiniz. RDWA ile aynı sunucu üzerinde kurgulanabilir. Eğer çok aktif bir trafiğiniz yok ise İkisi de web server üzerinde koştuğu için aynı sunucu üzerinde mimari edilmesi sorun yaratmayacaktır. Remote Desktop Virtualization Host (RDVH): RDS mimarisinin sanallaştırma teknolojisinin gelişmesi ile ortaya çıkan bu role için Hyper-V rolü üzerinde kurguladığınız sanal masaüstü sisteminizi yapılandırmayı ve yönetmenizi sağlayan rolüdür. Tam olarak nedir diye sorar gibisiniz. Hyper-V üzerinde VDI diye isimlendirdiğimiz Windows 10 gibi işletim sistemlerinden oluşturduğunuz sanal masaüstlerine erişim ve yönetim hizmetini sağlar. Size ait sanal bir masaüstünüz olduğunu ve her yerden internetinizi kullanarak erişebildiğiniz bir yapı hayal edin. İşte bu yapının perde arkasındaki rolümüz Hyper-V ve RDHVdir. Remote Desktop Licensing (RDL): RDL rolümüz RDS alt yapımızın lisans yönetimini yapmaktadır. RDS rolü Microsoft tarafından ekstra lisanslı bir ürün olarak servis edilmektedir. Windows Server Roles and Features üzerinden ücretsiz olarak kurup 120 gün test edebileceğiniz RDS rolü için süreniz bittiğinde lisans satın almanız gerekecektir. RDS için iki türlü lisans servis edilmiştir. Birincisi cihaz bazlı, ikincisi kullanıcı bazlı ihtiyaç ve talepleriniz doğrultusunda farklı lisans modellerini tercih ederek kullanımınıza devam edebilirsiniz. Doğru lisans seçimi ve fiyatlar için Microsoft ürün sağlayıcınızdan detaylı bilgi alabilirsiniz.
