There may have been better ways to accomplish the same goal, but I found this way to do exactly what I wanted to in a short amount of time.
You can of course pipe this into Export-CSV if you want so you have a nice spreadsheet to view. 🙂 So with that, you can easily run this against your enterprise and have the data you need. Much nicer than a sequential run through all systems. $SIDs = $rootkey.GetSubKeyNames() | Where " -f $Computer,$_.Exception.Message)Īs I mentioned before, since I elected to use runspaces again, I was able to run through around 4000+ systems in a couple hours. $rootkey = ::OpenRemoteBaseKey("Users",$computer) With that now decided, I had to figure out the best way to accomplish this goal.īecause this would be used to query some 4000+ systems, I decided to use runspaces again to handle several jobs at a given time to greatly speed up the query.īecause I am querying the registry remotely on the HKEY_Users key, I need something that can translate the SIDs to a friendly username that can be read. In this case, I went with the workstation registry query because I wasn’t confident that the logs would have as many users as the workstations would. HKEY_Users\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\\003601.
CACHE MODE IN OUTLOOK 2016 WINDOWS
You may consider that a more accurate (though ugly) description of this FSLogix setting would therefore have been “ Override machine-wide Outlook forced online mode policy on successful container attach”.įollow Jacques Bensimon on Twitter for more great Windows insights and tricks.Get-Mailbox -ResultSize Unlimited | Get-LogonStatistics | Select Name, ClientName, ClientMode Step 3 – Enable the policy to filter the usersĪnd this is where the previously alluded to FSLogix “ Set Outlook cached mode on successful container attach” machine policy comes in: once set, it causes FSLogix to use its “app masking” trickery to make the above NoOST entry appear to be set to 0 in any session in which a profile container was successfully attached, allowing the Outlook cached mode policies in step 1 to take effect - pretty cool!. Wait, so now nobody gets cached mode in any session? Not quite, see step 3.
** change 16.0 as needed to concord with your Office version KEY: HKLM\Software\Policies\Microsoft\office\16.0\Outlook\OST You now must also manually set an (undocumented) Outlook machine policy Registry entry (not exposed by any policy template) on all your session hosts to override the above user policies and force online mode: But now everybody gets cached mode in all logon sessions? Not quite, see step 2. Since FSLogix won’t do it for you, it’s up to you to enable Cached Exchange Mode for your users, typically via the relevant Outlook policies “ Use Cached Exchange Mode for new and existing Outlook profiles” and “ Cached Exchange Mode Sync Settings” (to set the desired sync period). So you just enable this policy and you’re all set, right? Not exactly!ĭespite this policy setting’s name and its promising description, it does not “set Outlook cached mode” but rather performs a little FSLogix kung fu (explained below) that results in cached mode being enforced, assuming the following steps have first been taken: Step 1 – Enable cached mode for everyone online mode depending on whether or not a profile container was successfully created or reattached at logon, thus avoiding the creation of a mailbox cache for users excluded from FSLogix profile handling or for any user whose profile container failed to attach for any reason at logon. Makes perfect sense: let FSLogix decide whether Outlook uses cached mode vs. VDI environments or elsewhere, you’ll likely have come across this FSLogix (not-really-a-)policy setting, “ Set Outlook cached mode on successful container attach”. If you’re among the many who’ve jumped on the FSLogix bandwagon to manage user profiles in your Microsoft WVD, Citrix CVAD, etc.
0 kommentar(er)
