Redirected Start Menu shortcuts not allowing "Pin to Start Menu" on context menu
This one just caught me out for a few minutes.
If you are using a redirected Start Menu, and you want to allow users to pin shortcuts to the Start Menu themselves, your shortcuts must all reside inside the Programs folder of your redirected Start Menu folder. Given the layout of the Start Menu in Windows 7 everything displays as if it were in the Programs folder anyway; but any items not in this folder will not display Pin to Start Menu on the context menu.
The rest of your GPO settings have to allow this as well, of course.
Save As permissions error when Libraries are disabled
When libraries are disabled, or otherwise mucked around with, a number of programs will complain about permissions when choosing Save As, although clicking OK does then present the user with a save dialog as normal. Windows is trying to point users at a daft location first, and when it can't, it complains and then presents them with My Documents, as it should do in the first place.
To prevent computer stupidity and user confusion, the following combination of user GPOs and user GPPs should, just about, get you there. Replace "H:\" with whichever drive letter you map the homeshare to.
User Config > Policies > Admin Templates > Windows Components > Windows Explorer > Common Open File Dialog > Items displayed in Places Bar
- I set Item 1 to the mapped home drive letter e.g. H:\. Item 2 I set to H:\My Pictures but only Item 1 should be necessary.
Office 2010 (using the custom ADM(X) files):
Microsoft Office 2010 > File Open/Save dialog box > Places Bar Locations > Places Bar Location 1
- Name "My Documents", path "H:\". You can fill out the rest of the locations as you please, I imagine.
Microsoft Excel 2010 > Excel Options > Save > Default File Location
Microsoft Powerpoint 2010 > Powerpoint Options > Save > Default File Location
Microsoft Word 2010 > Word Options > Advanced > File Locations > Default File Location
For right-click-save-as of attachments:
User Config > Preferences > Windows Settings > Registry
- right-click > new > registry item
- Action = Update; Hive = HKEY_CURRENT_USER; Key Path = Software\Microsoft\Office\14.0\Outlook\Options; Value name = DefaultPath; Value type = REG_SZ; Value data = H:\
For opened-attachments-then-save-as (because otherwise, it dumps the temp file in an AppData folder that the user doesn't have permission to and thus: error message)
User Config > Preferences > Windows Settings > Folders
- right-click > new > folder
- Action = Replace; Path = %HOMESHARE%\OutlookCache; Attributes = Hidden; then the last three checkboxes (delete files, allow deletion, ignore errors)
Above your homeshares (e.g. \\server\share\Staff, where a home directory would be \\server\share\Staff\username), go into Security > Advanced > Change Permissions. Click Add, Add "Domain Computers" and add permissions for: Read attributes, Create folders / append data, Write Attributes
Back in the policy you were just working on, go back to the registry section of preferences and add a new registry item
- Action = Update; Hive = HKEY_CURRENT_USER; Key path = Software\Microsoft\Office\14.0\Outlook\Security; Value name = OutlookSecureTempFolder; Value data = H:\OutlookCache
All this allows the computer to create a hidden folder in the users homedir that it uses when opening attachments from Outlook. Files are deleted when Outlook is closed so it shouldn't bloat and waste backup space; just in case, the replace action on the GPP will empty it anyway. When a user goes to save a document they have previously open with a double click, they are presented with this folder but no error message; they can then navigate as normal without panic. Using a hidden folder is preferable (in my thinking) from just using the %homeshare% root as otherwise, if they want to save the attachment to that location, they'll not be able to overwrite the read-only temp file. If they choose to overwrite the $document (2).docx file, that gets deleted when Outlook is closed.
This information was compiled from various sources with a lot of testing and faffing - the GPP folder needing %homeshare% took a while - so hopefully it being all in one place saves someone some aggro.