Veel organisaties zie je op dit moment een keuze maken tussen VDI en shared desktops. Ik ben echter van mening dat je niet moet kiezen, maar moet combineren. VDI en shared desktops vullen elkaar namelijk aan op het gebied van functionaliteit.
Het combineren van de twee kan juist extra voordeel opleveren. Een gecombineerde omgeving is over het algemeen goedkoper en flexibeler in te zetten.
Een van de klanten waar ik kom stelde de vraag of het mogelijk is de geluidsinstellingen te bewaren. Het bleek dat als je geluid dempt, uitlogt en weer inlogt, dat het geluid weer maximaal staat.
Aangezien RES Workspace Manager wordt gebruikt met een hybride profiel (zero profiling), dacht ik eerst dat ik wat instellingen had vergeten op te slaan. Na wat zoekwerk blijkt Windows de instellingen van het geluid op meerdere plekken op te slaan, waarvan de raarste HKCU\Software\Microsoft\Internet Explorer\LowRegistry\Audio (waar Windows per applicatie het volume op slaat).. Uiteindelijk kwam ik op het volgende lijstje:
Echter, nog steeds werd het volume niet goed onthouden en stond hij op 100% bij het opnieuw inloggen en reconnecten van een sessie. Op zich ook wel logisch. Blijkbaar zet Microsoft bij remote sessies het geluid altijd naar 100% bij een connect. Gezien het feit dat het geluid al aktief is bij het inloggen van de gebruiker en de registrykeys die RES Workspace Manager zet, te laat worden geïnjecteerd in het register van de gebruiker blijft het volume daardoor vol aan staan. RES WM doet helaas ook geen ‘sound service reset’ om het volume te herstellen, zoals ze bij muisinstellingen wel doen.
Uiteindelijk kwam ik via fora het tooltje volume.exe tegen van Christoph Kolbicz. Deze tool schrijft bij het veranderen van het volume, onder HKCU\Control Panel\Sound weg of het volume gedempt (mute) is of niet en hoe hoog het volume staat. Bij een connect/reconnect worden deze waarden van het volume herstelt.
Door deze tool op te nemen in de Custom Resources van RES Workspace Manager, wordt hij eenvoudig gedistribueerd naar de verschillende servers. Met een external task is hij bij het inloggen van een gebruiker af te trappen.
Vergeet daarbij niet de external task in te stellen op ‘Run task at logon after other actions’ en uncheck ‘Wait for task to finish before continuing’. Het eerste zorgt ervoor dat de eerder genoemde registry keys zijn geïmporteerd voordat de tool draait en het tweede zorgt ervoor dat de shell ooit nog geladen wordt. De tool blijft immers op de achtergrond draaien zonder te stoppen en als je blijft wachten tot hij klaar is, duurt het inloggen heel erg lang 
link naar volume.exe: http://www.kolbi.cz/volume.zip
Vanwege een tragere en niet al te grote WAN link van een cloud service center naar een klant, moest ik voor bepaalde data die door CAD programma’s nodig was, BranchCache inrichten. Een BranchCache Hosted Server download grotere kaarten en tekeningen in read-only mode, waarna de clients deze snel kunnen openen over het interne LAN in plaats van dat de data over de WAN verbinding naar elke client zou gaan.
Na inrichting van BranchCache voor Bestanden volgens de documentatie (http://technet.microsoft.com/library/ee649232(v=ws.10).aspx) bleek BranchCache niet helemaal te doen wat we hadden verwacht. De SMB cache bleef op 0 staan, terwijl die echt op moest lopen.
Troubleshooting tips voor BranchCache zijn echter lastig te vinden. In de deploymentguide is het troubleshoot gedeelte volledig verdwenen. Gelukkig is hij in de eerste versies van het document nog wel aanwezig (http://technet.microsoft.com/en-us/library/dd637794(v=ws.10).aspx) maar echt veel informatie staat er niet in.
Voor de zekerheid is in de GPO ingesteld dat BranchCache altijd ingeschakeld moet zijn op alle clients, ongeacht de grootte van de vertraging op het netwerk, door de retourlatentie op 0 in te stellen. Daarnaast ook de PeerDistSvc (BranchCache service) op automatisch starten gezet. Op de fileserver eenmalig het commando gegeven om de hashes van de bestanden (die nodig zijn voor BranchCache werking) direct te genereren via het commando hashgen –f C:\[shared directory]. Op dat moment kun je in het dos-venster de voortgang van het hashen volgen.
Maar wat er ook geprobeerd werd, BranchCache bleef weigeren. Uiteindelijk de gehele documentatie nog een keer doorgelezen. Bij het stuk ‘enable BranchCache on a file share’ begon me wat te dagen. BranchCache activeer je onder de optie ‘Only the files and programs that users specify are available offline’. Dat houdt in dat BranchCache Offline Folders gebruikt voor zijn functionaliteit. 
Offline Folders was echter op de clients uitgeschakeld, om te voorkomen dat gebruikers per ongeluk bestanden offline zouden plaatsen over de niet al te brede WAN verbinding. Nadat we deze optie voor de specifieke clients weer hadden ingeschakeld, werkte BranchCache direct.
Deze informatie (het activeren van Offline Files op de clients) wordt echter in geen van de documentatie van Microsoft genoemd. Misschien omdat dit “overduidelijk” blijkt uit het feit dat de optie op de server onder Offline Files valt in de share instellingen. Ik heb bij Microsoft in ieder geval aangegeven dat dit in de informatie van de pre-reqs van de client moet komen.