HyperV RDS 2012 cluster, trage boot / vage eventID meldingen

[HellBeast]

Ik heb een probleem waar ik zeer moeilijk uitkom. Bij een klant hebben we een RDS 2012 cluster draaien als Hyper-V VM's. Ik zal proberen om zo duidelijk mogelijk de situatie te schetsen. Vetgedrukt is fysiek:

Server 1 - Windows Server 2012 std (Hyper-V host)
Server 2 - Windows Server 2012 VM (sharepoint)
Server 3 - Windows Server 2012 VM (ontwikkel server)
Server 4 - RDS Server 2012 VM (Terminal Server)

Server 5 - Windows Server 2012 std (Hyper-V Host)
Server 6 - Windows SQL server 2012
Server 7 - Windows Server 2012 Connection Broker
Server 8 - RDS Server 2012 VM (Terminal Server)

Hardware: 2x IBM X3650M4 met 80GB aan geheugen. RDS servers hebben 4 virtuele processoren en beide 34GB aan memory. Beide hebben ze een C partitie van 100GB, waarvan ongeveer 45GB vrije ruimte en een D partitie van 150GB, met daarop rond de 75GB vrij aan ruimte.

Het domein is een Windows Server 2008 domein met 2 fysieke Windows Server 2008 std domain controllers.

Alle files (RDS profiles/VM disks/VM Config etc) staan op lokale storage op de twee fysieke servers.

Het probleem is dat er in de loop van de tijd een enorme traagheid is ontstaan in het opstarten van de RDS VM's. Op dit moment doen ze er bijna een uur over om op te starten. De andere VM's starten wel snel op. Wanneer de RDS servers eenmaal zijn herstart, dan is de performance gewoon goed.

Als ik in de eventlog kijk, dan zie ik de volgende meldingen:


(let op de tijd)




Er staan meerdere meldingen met dezelfde event ID en source, maar dan met andere onderdelen onder "Config" zoals:

\SystemRoot\System32\Config\DEFAULT
\SystemRoot\System32\Config\SAM
\SystemRoot\System32\Config\SECURITY
\??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT

Wanneer de VM is gestart, dan zie je later ook dezelfde eventID opkomen voor de profiles van de RDS gebruikers:

De toegangsgeschiedenis in component \??\C:\Users\Administrator.011\ntuser.dat is gewist waarbij 84 sleutels zijn bijgewerkt en 10 gewijzigde pagina's zijn gemaakt.

Dit voorbeeld is van de administrator, maar voor de andere gebruikers zie je ze ook voorbij komen.

Vandaag heb ik een malwarescan gedraaid met MBAM op beide servers en daarbij had ik wel wat gevonden (PUM-Hijack dingetjes), maar dit opruimen bleek niet het probleem op te lossen. Ik had een artikel gevonden van Windows Server 2008 Terminal Server, waarbij werd aangeraden om met de tool DEVNODECLEAN je registry te cleanen van vervuilde VSS backup restanten in de registry zelf. Ook dit heeft niet geholpen helaas.

Toen ik eenmaal bezig was met het register, heb ik een export gemaakt en die was bijna 500MB groot. Dit leek me nogal aan de grote kant. Daarop heb ik uiteraard gegoogled om een oplossing te vinden, maar het meeste wat ik vind gaat over UPHclean voor XP en Windows Server 2003 of over printerdrivers die het register zouden kunnen "bloaten", maar nergens een oplossing.

Normaliter kan ik redelijk wat info vinden met een eventID, maar op deze vind ik zeer weinig. Nu is deze klant voor ons nogal exotisch met deze configuratie (Hyper-V met RDS 2012 cluster) en ik heb dus weinig vergelijkingsmateriaal.

Heeft iemand een idee wat dit probleem kan zijn? Of wie kan me adviseren wat ik nog kan checken of doen? Dit weekend ga ik een chkdsk op de servers uitvoeren en een SFC /scannow. Als dat allemaal verder niet werkt, dan ben ik genoodzaakt een call bij Microsoft te plaatsen.

Alvast bedankt voor het reageren en als jullie info te kort komen: roep maar!

[Question Mark]

Is een herinstallatie niet gewoon sneller? Hijack achtige dingetjes klinken niet helemaal fijn op een server... Het zou niet mijn voorkeur hebben om een dergelijk systeem weer in produktie te brengen.

[HellBeast]

Aangezien het op twee RDS servers speelt, vind ik het niet handig om een herinstallatie te doen. Dan hebben we misschien over een half jaar weer hetzelfde probleem.

[Linke Loe]

Wat draait er allemaal aan software op die terminal servers?
Hoeveel concurrent users zijn erop ingelogd, gemiddeld en tijdens piektijden?

Persoonlijk snap ik die 34 GB geheugen voor de terminal servers niet zo. Als dit is omdat er heel veel gebruikers tegelijkertijd op werken, zou ik er persoonlijk voor kiezen om twee of drie terminal servers extra te installeren en max 16 GB toe te wijzen...

[HellBeast]

Software is niet zo bijzonder. Office 2010 en wat kantoorapplicaties van Dymo labelwriter software tot Google chrome en wat verzekeringstechnische software. Een As400 client en Citrix receiver. Er zijn max zo'n 40 users online. Gemiddeld rond de 30. Ze hebben bij het inkopen van de server er flink wat geheugen ingepropt, met het oogpunt dat er later nog VM's bij kunnen. Aangezien dat nu nog niet werd gebruikt, is het aan de RDS servers toegekend.

[Wim-Bart]

Software is niet zo bijzonder. Office 2010 en wat kantoorapplicaties van Dymo labelwriter software tot Google chrome en wat verzekeringstechnische software. Een As400 client en Citrix receiver. Er zijn max zo'n 40 users online. Gemiddeld rond de 30. Ze hebben bij het inkopen van de server er flink wat geheugen ingepropt, met het oogpunt dat er later nog VM's bij kunnen. Aangezien dat nu nog niet werd gebruikt, is het aan de RDS servers toegekend.

Waardoor je servers dus gewoon slecht performen. Te veel geheugen in een VM is waardeloos. Zeker als je host maar 80 GB heeft. Waarschijnlijk gaan je RDSen in de problemen raken met NUMA Spanning (als je 2 sockets per Server hebt). Bij iedere context switch wordt CPU Cache dus ongeveer volledig gewist en dat paar 1.000x per seconde

Ik zou als eerste de RDS servers eens terug brengen naar goede proporties, je moet hierbij denken aan:
Non Java intensieve servers:
2 x CPU + 4GB - 10 users
2 x CPU + 8GB - 20 users
2 x CPU + 12GB - 30 users
Java intensieve servers:
4 x CPU + 8GB - ~15 users
4 x CPU + 12GB - ~25 users
4 x CPU + 16GB - ~35 users

En daar gewoon niet boven uit komen. Daarnaast vraag ik me af waarom je D: disk zo vol is. En je C: disk (Fixed Page file?????).

Als eerste zou ik gewoon je Pagefile op fully automatic zetten, bij Server 2012 (R2) werkt een fixed size pagefile tegen je, zeker op een RDS/Citrix Server. Daarnaast Applicaties op D: En houdt deze klein, 10 - 20 GB is zat voor Fixed Applicaties. Nu staat je server alleen maar Admninistratie voor het OS te doen en de disken. Scheduled Defrag en andere RDS/Citrix ongewenste meuk uitzetten (bijvoorbeeld via GPO):

code:

@ECHO OFF

Call :tsk "\Microsoft\Windows\AppID\PolicyConverter"
Call :tsk "\Microsoft\Windows\AppID\VerifiedPublisherCertStoreCheck"
Call :tsk "\Microsoft\Windows\Application Experience\AitAgent"
Call :tsk "\Microsoft\Windows\Application Experience\ProgramDataUpdater"
Call :tsk "\Microsoft\Windows\Autochk\Proxy"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\Consolidator"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\KernelCeipTask"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\UsbCeip"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\Server\ServerCeipAssistant"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\Server\ServerRoleCollector"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\Server\ServerRoleCollector-RunOnce"
Call :tsk "\Microsoft\Windows\Customer Experience Improvement Program\Server\ServerRoleUsageCollector"
Call :tsk "\Microsoft\Windows\Defrag\ScheduledDefrag"
Call :tsk "\Microsoft\Windows\Power Efficiency Diagnostics\AnalyzeSystem"
Call :tsk "\Microsoft\Windows\Server Manager\ServerManager"
Call :tsk "\Microsoft\Windows\Windows Error Reporting\QueueReporting"


GOTO End

:tsk
  schtasks /change /TN %1 /DISABLE
  GOTO :EOF

:End

Daarnaast is 500MB wel heel erg groot. En ik neem aan dat je dus niet met roaming profiles werkt want anders haal je geen inlog tijden van 10-25 seconden, wat normaal is op een server van 30 users per server.

Ik zou eerst eens beginnen met het herbouwen van je server. Daarna iedereen roaming profiles geven en deze NIET sharen met Windows Werkplekken (dus speciale TS profielen). Daarna wat tuning doen op Office, zoals cached modus met GPO uitzetten op Outlook. En de bekende registry tweaks uitvoeren zoals:

code:

Disable Last Access Timestamp  Yes
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
NtfsDisableLastAccessUpdate=dword:00000001  

Disable Large Send Offload  No 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters]
EnableOffload=dword:00000000
  
Disable TCP/IP Offload  No 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
DisableTaskOffload=dword:00000001  

Increase Service Startup Timeout  No  
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control] 
ServicesPipeTimeout=dword:0002bf20  

Hide Hard Error Messages  No 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows] 
ErrorMode=dword:00000002 
 
Disable CIFS Change Notifications  No  Disable Logon Screensaver  No 
[HKEY_USERS\.DEFAULT\Control Panel\Desktop]
ScreenSaveActive="0"

Disable Clear Page File at Shutdown  Yes  
[HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management] 
ClearPageFileAtShutdown=dword:00000000
  
Disable Background Defragmentation  Yes 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction]
Enable="N"
 
Disable Background Layout Service  Yes 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OptimalLayout]
EnableAutoLayout=dword:00000000
  
Disable Bug Check Memory Dump  Yes  
[HKLM\SYSTEM\CurrentControlSet\Control\CrashControl]
CrashDumpEnabled=dword:00000000
LogEvent=dword:00000000
SendAlert=dword:00000000  

Disable Hibernation  Yes  
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power]
Heuristics=hex:05,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,3f,42,0f,00
  
Disable Memory Dumps  Yes  
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
CrashDumpEnabled=dword:00000000 
LogEvent=dword:00000000 
SendAlert=dword:00000000  

Disable Mach. Acct. Password Changes  Yes  
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
DisablePasswordChange=dword:00000001  

Reduce Event Log Size to 64K  Yes  
[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application]
MaxSize=dword:00010000

[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security]
MaxSize=dword:00010000

[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\System]
MaxSize=dword:00010000

En de volgende services disablen:

code:

Background Intelligent Transfer Service
Function Discovery Resource Publication
Offline Files

Daarnaast zou je via registry injections, custom ini, logoff-scripts files (kan je via GPO/GPP's implementeren) de volgende tweaks kunnen uitvoeren:
Java cache uitzetten of wissen bij uitloggen.

En tips van de dag:
Fileserver voor opslag data, niet op een RDS Server (heb je sowiso nodig voor roaming profiles);
Printserver inrichten en deze laten communiceren met de printers, en printdrivers pre-stagen.

[HellBeast]

Bedankt voor je reactie, maar geen van de (overigens goede) tips heeft impact op mijn probleem. Zelf ben ik weer iets verder gekomen. Ik zag dat de file:

c:\windows\system32\config\software 1.7GB groot was op beide servers!!

In de registry heb ik gezocht en ik denk dat het in de volgende sleutel zit:

HKLM\software\windows\currentversion\setup\pnplockdownfiles

Wanneer ik deze key probeer te openen, dan crasht regedit. Met regalyzer heb ik hetzelfde resultaat. Waarschijnlijk omdat de keys die eronder zitten inmiddels zo groot zijn dat de registry editors daarvan crashen!

[Wim-Bart]

c:\windows\system32\config\software van 1.7 gb is extreem groot. Er moet iets zijn met Admin toegang wat dat veroorzaakt. Hopelijk zijn je gebruikers geen administrator.

[HellBeast]

Dat zijn ze zeker ook niet. Ik vermoed iets met printers (of met VSS), maar omdat ik niet in de sleutel kan kijken kan ik daar niet zeker van zijn. Ik moet dus uitzoeken hoe ik een cleanup kan doen.

[ Voor 3% gewijzigd door HellBeast op 30-03-2014 09:15 ]

[Razwer]

Ten eerste, bah, Nederlandse foutmeldingen.
Engels OS, Nederlandse MUI, Engels voor de admins, zo heb je nog eens wat aan googlen, maargoed.
Dat die map zo groot is betekent dat je HKLM hive zwaar vervuild is. Wat voor exotische zaken draai je op die bak dat en zoveel vuil in HKLM zit? Ik zou dat eens gaan monitoren met procmon.

Enige redding is opnieuw installeren en uitzoeken wat de vervuiling veroorzaakt. Het feit dat het zo groot is is ook de reden van het trage booten. Die bak parsed eerst je hele registry voordat ie door start.

Overigens het advies van Wim-Bart opvolgen over BITS uit te zetten zou ik absoluut niet doen. Dit mechanisme word gebruikt om onder andere updates binnen te harken.
TCP offloading uit zetten werkte vroeger nog wel eens positief maar maakt tegenwoordig geen verschil uit en heeft in bepaalde gevallen een performance penalty.

Roaming profiles is op zich een must met meerdere RDS servers, al heeft dat geen impact op je registry hive. HKCU word opgeslagen in ntuser.dat en staat dus niet in die c:\windows\system32\config\software file.

[ Voor 4% gewijzigd door Razwer op 30-03-2014 14:04 ]

[Zwelgje]

niet toevallig SQL 2012 SP1 of componenten daarvan op die machines geïnstalleerd?

er is een issue met SP1 elke keer weer de installer aftrapt en in een "loop" komt en je registry volpropt met key's...

http://support.microsoft.com/kb/2793634

[HellBeast]

Nee, geen SQL op de terminal server. Ik was die ook al tegengekomen, dat artikel.

Ik ga eens kijken of ik niet die config/software kan rebuilden. Zou via de recovery console moeten kunnen. Gelukkig is het een VM, dus snapshot of clone maken en het risico dat je iets kapot maakt is uit te sluiten.

Op de RDS servers draait echt niet iets wat ik zou kunnen aanwijzen als exotisch. Zelf denk ik wel aan de Dymo labelwriter software. Die is op zich niet bedoeld voor een RDS omgeving. (Is ook niet supported door Dymo zelf)

[Wim-Bart]

HellBeast schreef op zondag 30 maart 2014 @ 19:36:
Nee, geen SQL op de terminal server. Ik was die ook al tegengekomen, dat artikel.

Ik ga eens kijken of ik niet die config/software kan rebuilden. Zou via de recovery console moeten kunnen. Gelukkig is het een VM, dus snapshot of clone maken en het risico dat je iets kapot maakt is uit te sluiten.

Op de RDS servers draait echt niet iets wat ik zou kunnen aanwijzen als exotisch. Zelf denk ik wel aan de Dymo labelwriter software. Die is op zich niet bedoeld voor een RDS omgeving. (Is ook niet supported door Dymo zelf)

Dymo software en drivers zouden geen probleem moeten zijn. Niet ondersteund maar tot nu toe in RDS/Citrix omgevingen geen problemen mee tegen gekomen. Wat wel veel ellende veroorzaakt is koppelen van client printers, maar die veroorzaken alleen problemen in de user profielen, vooral omdat ze tig keer opgeslagen worden met iedere keer een sessienummer. Drama, met Citrix los je dit op door legacy names te gebruiken maar ik weet niet of dat met RDS ook zo is.

Overigens, BITS als Feature kan je gewoon uitschakelen. Geen enkel probleem met updates. Standaard wordt dat niet gebruikt wanneer je geen spul draait welke services aanbied welke BITS ondersteunen zoals WSUS. BITS service kan je gewoon op manual zetten net zoals Windows Update service want die worden vanzelf actief wanneer je handmatig een Windows update doet wat wenselijk is op een server wanneer je geen SCCM of WSUS draait.

Maar waar ik me meer zorgen over maak is je HKLM size, en dan het onderdeel wat beschermd is tegen lezen, ok de SAM onderdelen zijn niet te lezen, maar overige zoude gewoon toegankelijk moeten zijn voor Administrators. Ik vraag me af wat er aan de hand is. Zou ook een corruptie kunnen zijn in het bestand, maar op 2 machines is heel vaag. Lijkt wel op een virus of een rootkit.

[Razwer]

Wim-Bart schreef op zondag 30 maart 2014 @ 20:56:
[...]
Overigens, BITS als Feature kan je gewoon uitschakelen. Geen enkel probleem met updates. Standaard wordt dat niet gebruikt wanneer je geen spul draait welke services aanbied welke BITS ondersteunen zoals WSUS. BITS service kan je gewoon op manual zetten net zoals Windows Update service want die worden vanzelf actief wanneer je handmatig een Windows update doet wat wenselijk is op een server wanneer je geen SCCM of WSUS draait.

Welke zelf respecterende engineer gebruikt er geen WSUS? En wat is de toegevoegde waarde van het disablen van BITS?

"Werken in de automatisering" word het soms nog wel eens genoemd. Servers met het handje patchen moet je niet willen. Alleen bij hoge uitzondering.

[ Voor 18% gewijzigd door Razwer op 30-03-2014 22:56 ]

[HellBeast]

Razwer schreef op zondag 30 maart 2014 @ 22:51:
[...]

Welke zelf respecterende engineer gebruikt er geen WSUS?

De enigineer die van de klant te horen krijgt: "Dat doen we wel zelf en daar willen wij jullie niet voor betalen."

Ja, die klanten bestaan. (Jammer genoeg)

[Question Mark]

Wim-Bart schreef op vrijdag 28 maart 2014 @ 23:04:
[...]
Waardoor je servers dus gewoon slecht performen. Te veel geheugen in een VM is waardeloos. Zeker als je host maar 80 GB heeft. Waarschijnlijk gaan je RDSen in de problemen raken met NUMA Spanning (als je 2 sockets per Server hebt). Bij iedere context switch wordt CPU Cache dus ongeveer volledig gewist en dat paar 1.000x per seconde

Numa spanning staat default aan, maar is simpel uit te zetten. Met 34 GB memory per VM kan deze gewoon op één Numa node draaien. Het is wel altijd een punt om rekening mee te houden.

Expand How to Configure Virtual NUMA for VMM

@TS: Het zou mijn voorkeur hebben om in elk geval een extra RDS server op te bouwen, de software te installeren en kijken op welk moment dit gedrag weer terugkomt.

Verder heeft er gewoon Hijack-achtige software op gedraaid, die software had nooit geinstalleerd mogen of kunnen worden. Security-wise zit er dus nog iets niet goed in je image of processen. Ik zou dat als allereerste gaan dichten.

[Killah_Priest]

Question Mark schreef op maandag 31 maart 2014 @ 09:23:
Verder heeft er gewoon Hijack-achtige software op gedraaid, die software had nooit geinstalleerd mogen of kunnen worden. Security-wise zit er dus nog iets niet goed in je image of processen. Ik zou dat als allereerste gaan dichten.

Daarom ook altijd applocker gebruiken op een TS als het even kan, alleen al om te voorkomen dat er rare applicaties gedraaid worden (vooral vanuit de appdata)

[HellBeast]

Onze klant heeft de RDS servers zelf in beheer. Wij hebben als externe partij de omgeving geinstalleerd en 6x per jaar een beheerdag ter ondersteuning. Wat er allemaal in de tussentijd verder op gebeurt is dan ook niet bekend en hebben wij geen invloed op. Al zie ik echt niks raars verder aan software draaien.

[Razwer]

mjah maar je zit wel met de gebakken peren. Ik raad je toch sterk aan om de adviezen die Mark en ik gaven niet in de wind te slaan en eventueel met de klant om te tafel te gaan zitten om een plan te schetsen hoe dit op te lossen. En anders over de schutting gooien...

[HellBeast]

Ik heb inmiddels een call aangemaakt bij Microsoft. Voor de goede orde zal ik het resultaat hier uiteraard neerzetten.

[HellBeast]

Ik vermeld, zoals beloofd, nog de afloop van dit verhaal.

Het onderzoek van Microsoft is afgerond. Ze hebben de oorzaak wel gevonden, maar er is alleen geen oplossing.

De oorzaak is de printerspool files. Normaliter is het zo, dat als een RDS user netjes afmeldt, dat er dan een cleanup plaatsvind voor de redirected printers. De RDS users bij deze klant sluiten hun sessie niet netjes af. Ze gebruiken het kruisje rechtsbovenin. De sessie is dan "disconnected". Er draait een Group policy die disconnected sessions na een uur automatisch verbreekt. Op dat moment vindt die cleanup niet plaats en blijft er troep in het register achter.

Er zijn 3 dingen om dit te voorkomen:

1. Users netjes laten afmelden
2. De Group policy uitzetten die de disconnected sessions verbreekt. De users nemen dan hun oude sessie steeds weer over.
3. Easyprint gebruiken van Microsoft. Dit is een soort universal printdriver van Microsoft, die dit probleem omzeilt. (Het zijn de 3rd party printerdrivers die blijven "hangen".)


Ze kunnen het register niet schonen, omdat het register simpelweg te groot is geworden. Geen enkele editor kan omgaan met deze grote bestanden. Dus het wordt een herinstallatie van beide RDS servers.
Gelukkig wilde de klant toch al van Windows Server 2012 naar Windows Server 2012R2, dus doet het iets minder "pijn".

[Question Mark]

Thx voor je feedback! Erg nuttig.

Hoe ga je de issue trouwens voorkomen in de nieuwe installatie? De MS printerdriver(s) gebruiken of speelt deze issue niet meer in 2012R2.

[ Voor 65% gewijzigd door Question Mark op 24-04-2014 11:19 ]

[Razwer]

idd, nuttig om te weten, ook voor mij
Overigens maken wij nooit gebruik van 3rd party print drivers. We gebruiken hier altijd Easy Print. Mocht dat niet voldoen gebruiken we ScrewDrivers. http://www.tricerat.com/p...ify-printing/screwdrivers
Misschien heb je hier iets aan.

[HellBeast]

We gaan een combinatie doen. Ten eerste instrueren we de gebruikers om netjes af te melden. Daarna zetten we de group policy uit. Als mensen dan nog steeds niet netjes afmelden, dan blijft de sessie bestaan. Wanneer ze daarna weer aanmelden, dan nemen ze hun oude sessie weer over.

Mocht het dan daarna voorkomen dat we een RDS User CAL probleem krijgen, dan kijkt de systeembeheerder in de connection broker en meldt hij de disconnected sessies af en geeft daarna de "stoute gebruikers" ongenadig op hun flikker.

Easy print heb ik nog geen ervaring mee, dus dat moet ik eerst uitzoeken en dan beslissen of ik dat wil implementeren.

[Question Mark]

HellBeast schreef op donderdag 24 april 2014 @ 14:42:
We gaan een combinatie doen. Ten eerste instrueren we de gebruikers om netjes af te melden. Daarna zetten we de group policy uit. Als mensen dan nog steeds niet netjes afmelden, dan blijft de sessie bestaan. Wanneer ze daarna weer aanmelden, dan nemen ze hun oude sessie weer over.

Test dan wel even goed wat er gebeurd als er een server herstart wordt vanwege onderhoud/patchen, waar nog lopende sessies op bestaan. De kans bestaat nl. dat deze sessie ook niet volledig juist afgemeld wordt, waardoor je uiteindelijk hetzelfde probleem gaat krijgen. Datzelfde overigens via remote afmelden door een beheerder...

Ik zou hiernaast nog even goed naar de printerdrivers kijken. Zijn deze gevalideerd om te werken met RDS, of zijn er reeds nieuwere uitgebracht die dit probleem niet hebben?

Wat is overigens de reden om geen easyprint te gebruiken? Dan heb je een 100% ondersteunde oplossing, die dit probleem niet kent. Ik zou dat eerst even goed uitzoeken voordat je nu al een oplossingsrichting kiest.

[ Voor 3% gewijzigd door Question Mark op 24-04-2014 14:51 ]

[HellBeast]

Als de systemen worden herstart, wordt er eerst een controle gedaan via de connection broker. Dan kunnen we precies zien of er nog (gedisconnecte) sessies draaien.

Een controle van de printerdrivers kan inderdaad geen kwaad. Gaan we zeker doen.

Ik ken easyprint niet, dus ik weet niet of daar nog haken en ogen aan zitten. Als het kan, ga ik het zeker gebruiken.

[HellBeast]

De nieuwe RDS 2012 R2 servers draaien nu netjes. Alleen staan de TS user disks nog op 1 van de oude Terminal Servers. Ik had gedacht deze makkelijk te migreren, door de Hyper-V disk waarop ze stonden te koppelen aan een nieuwe RDS server. Dan verwijzen naar de nieuwe RDS server in de eigenschappen van je verzameling en de group policies aanpassen, maar dat ging niet zo makkelijk. Ik kreeg allemaal foutmelding met betrekking tot verwijzingen naar de oude RDS server.

Ik ga de TS user disks binnenkort naar een centrale plek migreren (SAN storage/dikke File server) en dan maar alles opnieuw aanmaken en de relevante data gewoon kopieren. (aangezien je deze disks gewoon kan mounten en de content kan kopieren).

[Powermage]

Het is een redelijke schop van dit topic, maar bij een klant hebben we vergelijkbare problemen gehad en gezien, veel users die disconnecten en die dankzij een nachtelijke reboot eraf geforceerd waren.

HellBeast schreef op donderdag 24 april 2014 @ 09:55:
Ze kunnen het register niet schonen, omdat het register simpelweg te groot is geworden. Geen enkele editor kan omgaan met deze grote bestanden. Dus het wordt een herinstallatie van beide RDS servers.
Gelukkig wilde de klant toch al van Windows Server 2012 naar Windows Server 2012R2, dus doet het iets minder "pijn".

Ik geef deze schop om vooral even toe te voegen dat een in-place-upgrade naar R2 ook voldoende is, deze bouwt de key opnieuw op, let wel op, normaal zien we dat een in-place-upgrade onder de 45 minuten haalbaar is, deze machines namen ruim 3 uur in beslag.

[Killah_Priest]

Het register zou in feite gewoon via een simpel powershell script op te schonen moeten zijn, vreemd dat de support van MS daar niet mee gekomen is.
En easyprint zou iedere beheerder die met RDS omgevingen werkt eigenlijk moeten kennen.

[HellBeast]

Powermage schreef op woensdag 12 november 2014 @ 16:49:
Het is een redelijke schop van dit topic, maar bij een klant hebben we vergelijkbare problemen gehad en gezien, veel users die disconnecten en die dankzij een nachtelijke reboot eraf geforceerd waren.


[...]


Ik geef deze schop om vooral even toe te voegen dat een in-place-upgrade naar R2 ook voldoende is, deze bouwt de key opnieuw op, let wel op, normaal zien we dat een in-place-upgrade onder de 45 minuten haalbaar is, deze machines namen ruim 3 uur in beslag.

Bedankt voor je toevoeging! Heel nuttig.