I've got quite a bizarre issue here that I believe might actually be a bug in Outlook 2013. Here's what I've got going on:
We're applying a variety of AutoArchive settings to our clients via a GPO using the Office 2013 ADMX templates from a Central Store. As I'm sure everyone here knows, a GPO is just an easy, fancy way to make a change to a registry setting. Each of these registry settings are detailed in the "office2013grouppolicyandoctsettings.xlsx" file that is included when you download the Office 2013 ADMX files. According to this file, the AutoArchive settings from the GPO go here:
The GPO is working properly, as I can see the values being populated in this key. In fact, I've even deleted the entire "preferences" key, forced a gpupdate, and then watched as the "preferences" key gets repopulated from the GPO. This is NOT an issue of the GPO not being applied.
Best I can tell, Outlook is just simply ignoring these registry keys for some reason on some computers. I've got a few computers that are inheriting this same GPO that are working just fine. In fact, I can even delete the preferences key, open Outlook, and see the archive settings go back to default. I can then reapaply the GPO (or simply reimport the preferences key), and everything goes back to our custom settings. This is NOT happening on a few computer though (this the reason for this post). Seemingly only on newly configured laptops does this seem to be a problem, as the computers it's working on have been inheriting this GPO for several weeks now.
Any thoughts on what to do here? What's the best way to get this reported to Microsoft without being charged for a support incident?
That's great news actually! When I didn't get a response to this last week, I went ahead and opened up a ticket with Microsoft Professional Support. So far, the only suggestion has been to uninstall Office and then reinstall, which I'm going to try this morning. I doubt it is going to make a difference.
If it would be helpful to provide a case number for my open ticket with MPS, please let me know and I can provide a case number.
- Edited by arp.parker Thursday, May 16, 2013 12:26 PM
Hi arp.parker. I've got almost the same issue here: AutoArchive and Junk email prefences are not applied on Outlook 2013 (tried with 4 installations, all I have - Win7Pro 64-bit and Office 2013 H&B), but for example other policies are applied (eg disallow to add new accounts).
It happened only a couple of times that the policy applied, but then it disappeared at the next gpupdate or GPO change. If I run a gpresult or a rsop.msc, policy looks applied, but effects actually don't.
I would really appreciate if you could keep this topic updated. Thanks!
Most definitely, will do! Your scenario sounds very, very similar indeed. We too are using Junk Mail settings (in a different GPO though), and I discovered while I was on the call with MS Professional support that most of those weren't being applied as well (but our macro security settings were--in the same GPO!).
I've been working with MPS this week, and they collected some ProcMon logs yesterday. Appears they are moving it up the chain, so as soon as I have an answer I'll be sure to update here.
Sort of, but nothing substantial. They've collected a lot of data from the computer and I've sent countless screenshots and registry/logging info over to them as they continue to run it up the chain.
At this point they've narrowed it down to affecting only Click To Run installs of Office 2013 (which I believe is likely a majority). We have an MSDN version of Office 2013 installed that works perfectly, and the folks at Microsoft have been able to replicate this. I just sent an email over this morning requesting an update, as it's been several days since I've heard anything from them myself actually.
Ultimately, I still haven't received a hotfix or gotten any kind of confirmation this is going to be fixed in any future updates. It's supposedly with their development group now, so hopefully this isn't much further away.
Thanks for the reminder actually! I had received a call a few weeks ago advising they'd have more information in a few days, but realized I still hadn't heard back. I just got off the phone with the Technical Lead on the case.
It has now been officially classified as a bug. There isn't yet any formal documentation on the issue or a hotfix/update to correct it. There is also no ETA on when this might happen, but the bug has been logged with the "Product Team". The Technical Lead advised that there it can be a time consuming process to get an update integrated into the release schedule and approved, so it may very well be months for all I know before an actual fix is available.
The case I opened with MPS is associated to the bug, so I should get an automated notification when it is resolved. I was also reassured that I can contact any of the few technicians I've been working with periodically to check on the status.
I'll try to remember to update this thread when I hear some good news!
As of last week about this time, no, there is not yet any official documentation. It's supposed to be coming soon though, and the case I opened with MPS has been associated to the bug internally, so I should receive a notification when further information is available. If I haven't heard anything in another week or two, I'm going to follow-up with the technical lead who was handling the case to inquire about the status.
Sorry, I've been meaning to update this for a week or so now. I did get a response back from Microsoft, but no one here with this problem is going to like the answer one bit. What appears to be happening here seems on the surface to be pretty sleezy. Let me explain.
First, let me just quote the exact response I received regarding this bug:
PG group has decided not to go further on this and As per http://technet.microsoft.com/en-us/library/cc179176.aspx the following documentation is available now.
“ Using Group Policy to manage Office 2013 is supported only in Office 365 ProPlus, in volume licensed versions of Office 2013, and in individual Office 2013 applications that are sold through retail stores or through volume licensing. “
Sure enough, that quote is taken verbatim from "Overview of Group Policy for Office 2013" TechNet article (this is the documentation linked to in the above quote). It appears to me that despite owning a completely legitimate and valid Office 2013 Professional license, we didn't acquire this license in a way that Microsoft approves of for using with Group Policy. The copies of Office 2013 that we are using came bundled with the Dell laptops we purchase, so they are OEM copies of Office that installed using Click To Run (which is new for Office 2013).
I had a sneaking suspicion when troubleshooting this with Microsoft that this might be the direction this was heading based on some of the questions and information they were asking for. At one point they got really hung up on precisely how the software was installed, and based on my experience with Office 2013 so far, it appears that all OEM copies of Office (or anything that comes preloaded on a machine) uses Click To Run. Click To Run in and of itself doesn't appear to be the culprit though, as I think that the Office 365 versions of Office 2013 also use Click To Run installers. Once all this started to come to light, the seemingly intermittent behavior I mentioned in my first post started to make a lot more sense. Turns out, all the machines I mentioned in my original post that were working were using MSDN copies of Office 2013, so these were installed using the standard MSI based installer. This bug appears to only affect a subset of Office 2013 installed using Click To Run.
Needless to say, we're pretty upset to hear that apparently an OEM version of Office 2013 Professional is apparently not as equal as a volume licensed or retail version of Office 2013 Professional. We do have plans to move to Office 365 soon, but this is going to put quite an additional burden on us in the meantime. We're going to try to run this up the chain via our reseller (Dell) and advise them that they are distributing software with their computers that Microsoft apparently is not fully supporting in an enterprise environment. I don't expect much to come of that, but if I hear anything from this angle, I will update when possible.
In addition, if there's any Microsoft personnel or MVP here that is able to perhaps provide some more clarity on this situation, it would be much appreciated. I have a hard time believing all this to be the case, but the only official word I've gotten from Microsoft at this point seems to indicate that this is indeed the case.
- Edited by arp.parker Friday, August 23, 2013 1:41 PM
Thanks arp.parker for the reply. As you wrote, this is absolutely a not-welcome reply from Microsoft, since there is indeed a problem and we are legitimate owner or Office copies. I don't understand why there should be such a discrimination which, by the way, to me doesn't seem a discrimination but an excuse for a problem they are not able/willing to solve.
I'll talk to our Dell representative to remark this problem, but I'm not that confident either...
Thanks anyway for following this ticket!EDIT: I've posted this http://community.spiceworks.com/topic/373897-gpo-not-applying-to-oem-office-2013 in Microsoft's page on Spiceworks.
- Edited by autopole Friday, August 23, 2013 2:08 PM
I'm coming in late to this discussion. My apologies.
I notice that the Microsoft documentation for the HKCU setting to prevent .PST files is HKCU\Software\Policies\Microsoft\office\15.0\outlook\preferences as noted by OP. When I install Office 2013, I don't get HKCU\Software\Policies\Microsoft\office\15.0\outlook\preferences, I get HKCU\Software\Microsoft\Office\15.0. (The HKCU\Software\Policies\Microsoft tree doesn't have an Office value.) If I manually create a key "outlook" and make a value named "DisablePST" (REG_DWORD, value "1"), then the ability to archive is unavailable (greyed out).
Admittedly, this is on a volume licensed version of Office 2013, so this may not be applicable to the situation being discussed, but it seemed interesting to me that the path to the required key is wrong and the value name appears to also be wrong.
Might be worth giving this a try?
I know this is an old thread, and I found it while looking for something else, however I am seeing an odd issue with AutoArchive in Office 2013 which may be related.
We are running Windows 10 (Both 1511 and 1607) with Office 2013 ProPlus Click To Run.
We set AutoArchive policy and disable File\Archive via GPO.
Both of these options are applying to our machines, however the option to set Archive options on subfolders is still available.
The default option is:
Checking the Radio Button for "Archive items in this folder using the default settings" picks up the GPO Policy defined options which is good, however you can still set individual archive settings for the mail folder.
Is this something that might be related to the original issue?
We are looking to disable this option too, so I might post again is\when I find the options.
One thing to note about Office CTR and Office MSI.
- Click To Run uses App-V technology so has a virtual registry space for Office Preferences. We have found that GPO's work as expected, however GP Preferences sometimes have to be written to the APP-V part of the registry to apply correctly.
I'm not sure if that is related to the above posts as people seem to be talking about GPO, but worth mentioning.
- Edited by Grumpy_Monkey Thursday, February 09, 2017 10:42 AM Updated with image