Terminal server. maximaal aantal users?

[Robinkos]

Beste tweakers,

Vorig jaar is onze terminal server vernieuwd naar een nieuwe HP Dl380 G9 voorzien van de volgende specs:
RAM: 128GB
CPU: 2x Xeon e5 2697 v3 (28 cores, 56 threads)
Opslag: 2x 1TB HP SSD (RAID 1) en 2x HP SAS 15K 2TB (RAID 1)
OS: Windows server 2019 Standard (up to date)

Echter horen wij af-en-toe nog wel eens klachten dat het systeem niet vooruit te branden is. CPU is nooit hoger dan 20& en RAM is max 70 tot 80% in gebruik. Er zijn dan op een drukke dag zeker 40 tot 50 clients aangemeld op het systeem.

Wanneer wij wat willen constateren qua prestaties merken wij zelf helemaal geen problemen. Systeem is niet traag en alles gaat ook gewoon prima.. Heel vreemd..

Ooit heb ik al wel eens ergens gelezen dat Microsoft zelf maximaal 25 gebruikers per systeem aanbevelen. ongeacht je specs. Is dit waar? Of wat doen jullie in dit soort situaties? Ik hoor graag jullie kennis en ervaring hierover!

Clients gebruiker hier onder andere de volgende apps:
Email (outlook)_
Office apps (word, excel)
PDF Xchange editor
DWG Trueview
Installworks (ERP)
Internetten (Firefox & Chrome)

[Voor 9% gewijzigd door Robinkos op 06-01-2022 16:50]

[Microkid]

Zijn die ervaringen op kantoor zelf of op thuis locatie? Dat kan natuurlijk nogal een verschil zijn.
En daarnaast: wat is er niet vooruit te branden? De hele sessie? Een individuele applicatie?
Zie je in Performance Monitor zaken die een indicatie geven waar het probleem zit?

[Jaaap]

Meestal is I/O in zo'n geval de bottleneck.
Kun je bij klachten over de schouders van de klager meekijken?

[Robinkos]

Microkid schreef op donderdag 6 januari 2022 @ 16:54:
Zijn die ervaringen op kantoor zelf of op thuis locatie? Dat kan natuurlijk nogal een verschil zijn.
En daarnaast: wat is er niet vooruit te branden? De hele sessie? Een individuele applicatie?
Zie je in Performance Monitor zaken die een indicatie geven waar het probleem zit?

Zowel thuiswerkers (met VPN) en op kantoor. Zowel Wi-Fi als bekabeld ervaren ze dit. Dat het niet aan het netwerk ligt weet ik vrijwel zeker.

De hele sessie loopt dat vast. ook simpel door de verkenner ''bladeren'' is al een drama. In performance monitor zie ik verder geen piek momenten oid.

[Microkid]

Misschien een optie om Hyper-V te activeren en gewoon een paar kleinere servers te maken?

[Xelefim]

40-50 gebruikers moet te doen zijn op zo een host

- draait die TS bare metal op de server of op een VM?
- zijn alle cpu's assigned ? is op host niveau alles ok(hypertreading etc) ?
- wat voor traagheden zijn er (bijvoorbeeld latency bij het typen van zaken, of echt dat de sessie vasthangt)
--> bij latency is het vaak internet-verbinding, bij sessie vasthangen is het vaak iets op de server

- klagen ze tegelijkertijd of apart?
- van welk systeem komen jullie? is het niet te wijten aan hun profile systeem (upd's? roaming profiles? waar staat de centrale storage?)
-...

[Zwelgje]

Microkid schreef op donderdag 6 januari 2022 @ 17:02:
Misschien een optie om Hyper-V te activeren en gewoon een paar kleinere servers te maken?

precies dat ja, je wilt toch ook je 'fault domain' niet te groot hebben. liever meerdere kleinere VM's met 10/12 gebruikers dan 1 grote bak met 80 man.

Hypervisor erop maakt het ook nog eens makkelijk met snapshots voor een belangrijke update of aanpassing in het systeem en backups

heb je deze patch overigens ook geïnstalleerd? hoeft niet je issue te zijn maar bij veel andere klanten van mij heeft dit wel geholopen

https://www.bleepingcompu...es-remote-desktop-issues/

ik heb in het verleden ook genoeg issues gehad met 'large send offloading' op de NIC van machines, veelal in HyperV scenarios maar ook bij fysieke bakken had ik genoeg issues met offloading aan. performance van het netwerk was dan slecht en dat veroorzaakte ook de ervaren 'traagheid' op de RDS servers. server is niet traag maar de netwerkstack stuur de pakketjes terug dat het 'stroperig' werd ervaren en dus 'server is traag' (quad non)

[Voor 42% gewijzigd door Zwelgje op 07-01-2022 04:41]

[Robinkos]

Xelefim schreef op donderdag 6 januari 2022 @ 17:17:
40-50 gebruikers moet te doen zijn op zo een host

- draait die TS bare metal op de server of op een VM?
- zijn alle cpu's assigned ? is op host niveau alles ok(hypertreading etc) ?
- wat voor traagheden zijn er (bijvoorbeeld latency bij het typen van zaken, of echt dat de sessie vasthangt)
--> bij latency is het vaak internet-verbinding, bij sessie vasthangen is het vaak iets op de server

- klagen ze tegelijkertijd of apart?
- van welk systeem komen jullie? is het niet te wijten aan hun profile systeem (upd's? roaming profiles? waar staat de centrale storage?)
-...

- Gaat om een fysieke machine, geen VMWare of Hyper-V
- Alle CPU's zijn assigned
- Traagheid voornamelijk in gebruik van applicaties
- Klagen doen ze vaak individueel (melden ze helaas niet altijd allemaal)

[Kees-Jan]

Applicaties die frontend-backend draaien, dat is frontend op de TS en backend op een andere server (SQL of andere database?)
Opslag op een andere server?

IOps naar de backendserver(s) over het netwerk?
IOps in het algemeen, op alle servers?

[MAX3400]

Tja, kweenie hoe druk de mensen zijn (en welke services er allemaal draaien op die machine) maar hier hosten we op dit moment 15 users per sessie bij 16 vCPU en 64GB RAM. Als ik dat extrapoleer naar jouw setup, kom ik dus minstens op 192GB RAM maar dat is dus gebaseerd op niks

Even ter mijn info: staat Windows Search / Indexing aan of uit? En is dat dan per user / folder / systeem? Hoe staan alle shares (profiles, data, etc) geconfigureerd; staat Offline Caching aan/uit?

En dan even specifieker Office (Outlook): zijn hier alle best practices op toegepast omtrent caching / OST / PST / indexing / automapping / etc. etc. etc want als ik ergens al decennia ruzie mee heb (out of the box) is het Outlook, zowel in on-prem als hybrid omgevingen.

Zijdelings: leuk dat de disks RAID1 staan. Maar dit is per definitie een "trage" storage. Ik durf bijna te stellen (maar meten is weten) dat als je single disk draait (dus 1 SSD en 1 SAS disk) dat het meetbaar sneller is. Inherent aan RAID1 is namelijk dat niet alleen een commit op disk0 moet plaatsvinden, maar dat er ook gewacht gaat worden tot de commit op disk1 heeft plaatsgevonden; daarna gaat "het proces" pas de volgende commit uitvoeren.

[Robinkos]

Backend van een aantal mogelijk zware IOps vreten zijn:
- Microsoft SQL 2017 (op server nummer 2)
- StabiCAD Database (op server nummer 2)
- Data mappen (op server nummer 2)
- Pluriform Installworks (op server nummer 3)

De servers zijn onderling met elkaar verbonden via 10Gbit.

[Robinkos]

MAX3400 schreef op vrijdag 7 januari 2022 @ 09:16:
Tja, kweenie hoe druk de mensen zijn (en welke services er allemaal draaien op die machine) maar hier hosten we op dit moment 15 users per sessie bij 16 vCPU en 64GB RAM. Als ik dat extrapoleer naar jouw setup, kom ik dus minstens op 192GB RAM maar dat is dus gebaseerd op niks

Even ter mijn info: staat Windows Search / Indexing aan of uit? En is dat dan per user / folder / systeem? Hoe staan alle shares (profiles, data, etc) geconfigureerd; staat Offline Caching aan/uit?

En dan even specifieker Office (Outlook): zijn hier alle best practices op toegepast omtrent caching / OST / PST / indexing / automapping / etc. etc. etc want als ik ergens al decennia ruzie mee heb (out of the box) is het Outlook, zowel in on-prem als hybrid omgevingen.

Zijdelings: leuk dat de disks RAID1 staan. Maar dit is per definitie een "trage" storage. Ik durf bijna te stellen (maar meten is weten) dat als je single disk draait (dus 1 SSD en 1 SAS disk) dat het meetbaar sneller is. Inherent aan RAID1 is namelijk dat niet alleen een commit op disk0 moet plaatsvinden, maar dat er ook gewacht gaat worden tot de commit op disk1 heeft plaatsgevonden; daarna gaat "het proces" pas de volgende commit uitvoeren.

Outlook was ook een beste boosdoener in het begin. Dit hebben we al opgelost en daardoor zijn de prestaties wel verbeterd, maar blijkbaar nog niet voldoende

- PST bestanden van gebruikers staan op de SAS schijf (D)
- Cache ingeschakeld op ''Alles''. Gedeelde postvakken niet gecachet (sommige zijn 50+GB groot, dan is cachen een te grote opslag vreter)
- Microsoft Search en indexering staat ook uitgeschakeld

[MAX3400]

Robinkos schreef op donderdag 6 januari 2022 @ 16:57:
[...]

De hele sessie loopt dat vast.

Per medewerker? Voor iedereen tegelijk? Herstelt de sessie? Wordt iemand afgelogd? Is er data-loss? Wat zegt eventviewer?

ook simpel door de verkenner ''bladeren'' is al een drama.

Van waar naar waar? Welk protocol? Voor iedereen tegelijk? Voor 1 user? Gebeurt het ook als je een andere "verkenner" gebruikt dus niet explorer.exe maar (bijvoorbeeeeeeld) One Commander of RX Explorer?

In performance monitor zie ik verder geen piek momenten oid.

Welke metrics heb je bekeken? Als user? Als admin? Perfmon neem ik (vaak) niet serieus; op sysinternals (en andere sites) zijn veel betere tools te vinden. Heb je nog andere monitoring-tooling? Wat zegt die?

- Alle CPU's zijn assigned

Assigned? Aan wat? Staat HT aan of uit en is er getest met / zonder? Heb je al eens wat geprobeerd met affinity per "type proces"?

- Traagheid voornamelijk in gebruik van applicaties

Welke applicaties? Iedereen tegelijk? Per user? Wat is "gebruik"?

- Klagen doen ze vaak individueel (melden ze helaas niet altijd allemaal)

Niet melden = geen incident. Users opvoeden. Vastleggen & rapporteren "wat" ze de hele dag ervaren.

Backend van een aantal mogelijk zware IOps vreten zijn:

Mogelijk? En zo ja wanneer? Hoeveel? Voor welke applicatie? Impact dat dan de eindgebruiker? Impact op andere processen per server? File locks? Congestie op het netwerk?

De servers zijn onderling met elkaar verbonden via 10Gbit.

En? Ik heb hier 40Gbit wat ik soms dichttrek. Kortstondig maar wel vol. Dus 10Gbit zegt me niks. Anders dan dat je hier een apart netwerkje voor hebt? Drivers up-to-date? Settings per machine geoptimaliseerd (offloading / jumbo frames / etc / etc)?

PST bestanden van gebruikers staan op de SAS schijf (D)

Dus je terminal server is ook veredelde file-server? Zo ja, wat nog meer?? Waarom gebruik je nog PST?

Outlook was ook een beste boosdoener in het begin....

En de rest van alle vragen van me?


Lastige lijst met vragen maar de rode lijn is dat je heel veel zegt maar eigenlijk zonder enig "gemeten" handvat want wij kunnen niet op jouw omgeving kijken. En tegelijkertijd, ook de vragen van anderen, zijn relatief intermediate om incidenten / issues op een omgeving inzichtelijk te krijgen.

Vorig jaar is onze terminal server vernieuwd naar een nieuwe HP Dl380 G9

Wat is verhuisd? Is het spul opnieuw kaal geinstalleerd? Is er een restore teruggezet? Over welke resoluties hebben we het qua endpoints? In hoeverre staat hardware-acceleration uit / aan binnen bepaalde applicaties? etc?

[Voor 5% gewijzigd door MAX3400 op 07-01-2022 10:31]

[Zwelgje]

nieuwe G9? die g9 is in 2013 uitgebracht en de CPU die jij aangeeft te hebben is van Q3 2014.. 7 jaar oud dus

een 7 jaar oude architectuur willen gebruiken en dan topprestatie verwachten.. vergeet dat maar

[Blokker_1999]

Met 50 gebruikers ga je gewoon tegen de limieten van die machine aanzitten. SAS schijven hebben nu niet direct een immense throughput bijvoorbeeld.

[revolution-nl]

Sterk afhankelijk van het applicatiegebruik en de grootte van de farm, je wilt ook ruimte houden op je RDHost voor als er één rdshost in de farm uitvalt.

Stelregel die ik vroegah hanteerde was 15 -30 gebruikers.

[MAX3400]

Zwelgje schreef op vrijdag 7 januari 2022 @ 14:22:
nieuwe G9? die g9 is in 2013 uitgebracht en de CPU die jij aangeeft te hebben is van Q3 2014.. 7 jaar oud dus

een 7 jaar oude architectuur willen gebruiken en dan topprestatie verwachten.. vergeet dat maar

Nou, dat valt wel mee. Tot anderhalf jaar geleden heb ik ook een bucketload aan G9-blades gebruikt, allen met 128GB RAM. Daar haalde ik best redelijke resultaten mee op Server 2016 / Windows 10 als VM's.

[Audiowaste]

Nu heb ik in het verleden ook met InfraWorks gewerkt van BouwInfoSys en dat is ook wel een zware applicatie en ik vermoed dat InstallWorks hetzelfde is. Ik neem aan dat jullie de databaseserver voor InstallWorks en de clientserver gescheiden hebben (tenminste dat hoop ik)?

Het zou dan zomaar kunnen dat InstallWorks veel verkeer over de lijn trekt waardoor de RDP connectie vastloopt. Wellicht zou je hier wat dingen in kunnen controleren en testen om dat uit te sluiten.

[Killah_Priest]

MAX3400 schreef op vrijdag 7 januari 2022 @ 14:32:
[...]

Nou, dat valt wel mee. Tot anderhalf jaar geleden heb ik ook een bucketload aan G9-blades gebruikt, allen met 128GB RAM. Daar haalde ik best redelijke resultaten mee op Server 2016 / Windows 10 als VM's.

Maar met zulke oude hardware met tig gebruikers die ook nog x browsertabs, office applicaties en andere zaken tegelijkertijd draaien loop je wel erg snel tegen de limieten van zulke oude hardware aan.
Plus dat een RDS omgeving performant inrichten ook wel een goede planning vereist.

[Zackito]

Waar is deze server aangeschaft? Wie heeft de advisering gedaan? Je kan resources tegen een RDS aan blijven gooien maar er zit natuurlijk limieten aan zaken. Sowieso is de hardware verouderd qua snelheid is er veel veranderd de afgelopen 5 jaar.

Handig om een aantal zaken te monitoren:

- Latency op storage
- CPU queus
- Pagefile en RAM gebruik
- Latency op netwerk.
- Waar staan je profielen? Of gebruik lokale profielen?

EDIT:

Hoe staat je performance/power plan binnen Windows? Moet op high performance staan, iden voor BIOS.

[Voor 11% gewijzigd door Zackito op 07-01-2022 23:04]

[Zwelgje]

MAX3400 schreef op vrijdag 7 januari 2022 @ 14:32:
[...]

Nou, dat valt wel mee. Tot anderhalf jaar geleden heb ik ook een bucketload aan G9-blades gebruikt, allen met 128GB RAM. Daar haalde ik best redelijke resultaten mee op Server 2016 / Windows 10 als VM's.

ja redeljke resultaten en dat kan goed zijn, echter gebruikers wensen in 2021/2022 geen 'redelijke resultaten' maar dezelfde performance als een lokale laptop met GPU en 16gb ram en snelle en snappy UI performance.

'never size for average' is mijn stelregel bij het ontwerpen van dit soort omgevingen, anders loop je in no-time vast met apps die net iets meer vragen na een update

topicstarter: haal er nog eens de diverse optjmizers over

https://support.citrix.com/article/CTX224676

https://flings.vmware.com/vmware-os-optimization-tool

en ja, je hebt geen Citrix, je hebt geen VMware. maar deze optimizers zijn ook prima te gebruiken bij RDS omgeving op fysieke hardware. heb er goede ervaringen mee dat het soms net even wat beter werkt

[Voor 20% gewijzigd door Zwelgje op 08-01-2022 06:40]

[Zwelgje]

Zackito schreef op vrijdag 7 januari 2022 @ 16:35:

Hoe staat je performance/power plan binnen Windows? Moet op high performance staan, iden voor BIOS.

wel even oppassen dat je met Max performance ook je turbo boost mogelijkheden om zeep helpt, de CPU kan dan niet tijdelijke pieken naar een hogere klok. hoeft niet altijd een probleem te zijn maar met shitty apps die het moeten hebben van CPU ipv cores kan dat een ding zijn

beter in de BIOS op 'OS controlled' en het dan in Windows goed afregelen, die bepaald het dan lekker zelf.

sidenote: heb nog ergens een benchmark liggen, kan hem ff niet zo snel vinden maar OS controller komt er dan beter uit dan High performance.

maar mijn consultant antwoord: hangt er vanaf, goed testen. geen klant is hetzelfde

[MAX3400]

Zwelgje schreef op zaterdag 8 januari 2022 @ 06:38:
[...]


ja redeljke resultaten en dat kan goed zijn, echter gebruikers wensen in 2021/2022 geen 'redelijke resultaten'

Ach ja, moet ik dan herformuleren "redelijker resultaten dan wat topicstarter omschrijft"? Overigens waren de blades ingezet voor non-persistent VM's dus elke zoveel minuten waren er ook andere gedragingen op de omgeving dan "1x RDS spelen" zoals de topicstart.

Denk dat we verder wel hetzelfde erover denken; er zijn zoveel onbekende factoren per omgeving en per inrichting (en nu ook dit topic) dat er geen standaard verhaal is hoe iets moet worden ingericht. Troubleshooting is wel vrij universeel want de techniek tussen 2 omgevingen is niet anders dus de tools & kennis zou bekend moeten zijn

[Oogje]

Robinkos schreef op vrijdag 7 januari 2022 @ 09:20:
[...]


Outlook was ook een beste boosdoener in het begin. Dit hebben we al opgelost en daardoor zijn de prestaties wel verbeterd, maar blijkbaar nog niet voldoende

- PST bestanden van gebruikers staan op de SAS schijf (D)
- Cache ingeschakeld op ''Alles''. Gedeelde postvakken niet gecachet (sommige zijn 50+GB groot, dan is cachen een te grote opslag vreter)
- Microsoft Search en indexering staat ook uitgeschakeld

Ik zie hier voor mij 2 grote red flags, caching betekent dat er een ost file aangemaakt en bijgehouden wordt en pst files zijn ruk. Als je dat maal 50 doet op dezelfde server, the horror.

Online mode voor alles en pst richting de uitgang, daar zou ik mee beginnen.

[remco_k]

@Robinkos Zit er zo'n write cache module in de G9? Zo niet, dat kan een enorm verschil maken.
Zoiets: https://www.nowthatsit.nl/hp-534562-b21.html

[HKLM_]

Robinkos schreef op vrijdag 7 januari 2022 @ 09:20:
[...]


Outlook was ook een beste boosdoener in het begin. Dit hebben we al opgelost en daardoor zijn de prestaties wel verbeterd, maar blijkbaar nog niet voldoende

- PST bestanden van gebruikers staan op de SAS schijf (D)

Als je je performance van Outlook nog wil verbeteren zou ik afstappen van legacy meuk als pst files en al helemaal niet over het netwerk… PST files over het netwerk is totaal niet best practices.

Geen idee wat voor Exchange je draait maar ik zou direct een projectje laten starten om de PST files naar Exchange Online archive te migreren.

MAX3400 schreef op vrijdag 7 januari 2022 @ 14:32:
[...]

Nou, dat valt wel mee. Tot anderhalf jaar geleden heb ik ook een bucketload aan G9-blades gebruikt, allen met 128GB RAM. Daar haalde ik best redelijke resultaten mee op Server 2016 / Windows 10 als VM's.

Maar kocht je die ook nieuw? TS heeft vorig jaar nieuwe G9 servers gekocht en G10 is al lang op de markt dat het prijs verschil met een G9 of G10 verwaarloosbaar is zelf voor een MKB bedrijf. @Anoniem: 37297 Waarom is er gekozen voor G9 servers en niet voor een generatie nieuwer? Afhankelijk van het type G9 zijn die over vier jaar EOSL

[Voor 32% gewijzigd door HKLM_ op 08-01-2022 15:11]

[Robinkos]

Oogje schreef op zaterdag 8 januari 2022 @ 09:36:
[...]

Ik zie hier voor mij 2 grote red flags, caching betekent dat er een ost file aangemaakt en bijgehouden wordt en pst files zijn ruk. Als je dat maal 50 doet op dezelfde server, the horror.

Online mode voor alles en pst richting de uitgang, daar zou ik mee beginnen.

Wij hebben juist gekozen om de postvakken te cachen om daarmee niet onze complete WAN verbinding dicht te trekken en de prestaties (naar ons idee) hoog te houden. Als al die gebruikers continu de mail moeten ophalen vanuit O365 kost dit ook erg veel data verkeer.

[Robinkos]

HKLM_ schreef op zaterdag 8 januari 2022 @ 10:36:
[...]


Als je je performance van Outlook nog wil verbeteren zou ik afstappen van legacy meuk als pst files en al helemaal niet over het netwerk… PST files over het netwerk is totaal niet best practices.

Geen idee wat voor Exchange je draait maar ik zou direct een projectje laten starten om de PST files naar Exchange Online archive te migreren.


[...]


Maar kocht je die ook nieuw? TS heeft vorig jaar nieuwe G9 servers gekocht en G10 is al lang op de markt dat het prijs verschil met een G9 of G10 verwaarloosbaar is zelf voor een MKB bedrijf. @Anoniem: 37297 Waarom is er gekozen voor G9 servers en niet voor een generatie nieuwer? Afhankelijk van het type G9 zijn die over vier jaar EOSL

De PST bestanden gaan niet ove rhet netwerk. Deze staan op de 2e SAS opslag van de terminal server zelf. Daarnaast gebruiken wij voor mail Office 365.

[MAX3400]

Robinkos schreef op maandag 10 januari 2022 @ 08:00:
[...]

Als al die gebruikers continu de mail moeten ophalen vanuit O365 kost dit ook erg veel data verkeer.

1 aanname en 1 uitspraak zonder metrics. Oftewel, zoals ik eerder al zei: issue bestaat dus niet.

Maar, en allicht is maandagochtend 08:00 niet de beste tijd; er is sinds vrijdagochtend een enorme bak aan info / suggesties / "onze bevindingen" / etc. gepost en dan is de enige inhoudelijke reply "O365 kost veel data verkeer"?

Het zou ons, en jou zeker, helpen om de laatste 15 replies eens zorgvuldig te lezen, op papier te zetten wat je ervan weet, wat je nog niet weet, welke kant je op kan qua idee / troubleshooting / conclusie en dat even aan ons terug te koppelen.

[HKLM_]

Robinkos schreef op maandag 10 januari 2022 @ 08:02:
[...]


De PST bestanden gaan niet ove rhet netwerk. Deze staan op de 2e SAS opslag van de terminal server zelf. Daarnaast gebruiken wij voor mail Office 365.

Dan nog blijf ik bij het advies om pst files uit te faseren en naar Online Archive te gaan. Zakelijk zitten daar alleen maar voordelen aan een EOA heeft standaard 100 GB en kan veilig groeien naar 1,5TB.

PST files kunnen ook tot 50GB maar de kans op data corruptie neemt bij een PST toe na mate de PST groter is. Dit is eigenlijk al de reden om geen pst files meer te willen.

[Voor 28% gewijzigd door HKLM_ op 10-01-2022 08:51]

[Oogje]

Robinkos schreef op maandag 10 januari 2022 @ 08:00:
[...]


Wij hebben juist gekozen om de postvakken te cachen om daarmee niet onze complete WAN verbinding dicht te trekken en de prestaties (naar ons idee) hoog te houden. Als al die gebruikers continu de mail moeten ophalen vanuit O365 kost dit ook erg veel data verkeer.

Goed punt. Dan zou je nog ervoor kunnen kiezen om 3 maanden te cachen bv.

[Zwelgje]

Oogje schreef op zaterdag 8 januari 2022 @ 09:36:
[...]

Ik zie hier voor mij 2 grote red flags, caching betekent dat er een ost file aangemaakt en bijgehouden wordt en pst files zijn ruk. Als je dat maal 50 doet op dezelfde server, the horror.

Online mode voor alles en pst richting de uitgang, daar zou ik mee beginnen.

Gelukkig heb je FSlogix en die gaat een stukje efficiënter om met PST/OST files (of wat voor files dan ook) in je profile disk.

normaliter moet je geen OST of PST op een share doen, maar met FSlogix kan dat prima. ik bouw omgevingen met 3500 man en OST's met FSlogix zonder shit

[MAX3400]

Zwelgje schreef op dinsdag 11 januari 2022 @ 19:29:
[...]

normaliter moet je geen OST of PST op een share doen, maar met FSlogix kan dat prima. ik bouw omgevingen met 3500 man en OST's met FSlogix zonder shit

Je moet inderdaad niet de folders redirecten of PST's koppelen over het netwerk. Voor Citrix kan je je caching in user-based VHDX opslaan vanaf UPM 7.18.

Oogje schreef op maandag 10 januari 2022 @ 12:36:
[...]

Goed punt. Dan zou je nog ervoor kunnen kiezen om 3 maanden te cachen bv.

Welk goed punt? Ik zie echt nergens metrics. En voor zover ik niet teruglees in het topic; het lijkt erop dat alles maar een beetje lokaal op die ene server rondhangt; als daar ook je PST's staan en (gedeelten) van OST, dan is een online connectie naar O365 helemaal niet interessant. Al krijgt elke user elke dag 1GB mail; dat is 50GB aan dataverkeer en dan tik je net aan 14Mbps aan voor continous traffic; als dat "ontlasten van de WAN lijn" heet, heb je grotere problemen...