Windows Explored

We disable Outlook PSTs within our organization via group policy. This setting resides in the registry at HKCU\Software\Microsoft\Office\14\Outlook and is enforced with a DWORD value equal to 1. In some cases, though, we allow certain uses to continue to use PSTs. Those who do use PSTs, however, don’t necessarily have the ability to move items into these PSTs. That, too, is also disabled by creating a DWORD called PstDisableGrow in HKCU\Software\Policies\Microsoft\office\14.0\outlook\PST. If the value is to enable this, then you will encounter the following warning or error message when trying to copy or move item(s) into the PST: “Cannot copy the items. You don’t have appropriate permission to perform this operation”

or “Cannot move the items. The items cannot be moved. It was either already moved or deleted, or access was denied.”

Now, for those user’s who do need to be able to move items into PSTs, we simply delete the PstDisableGrow DWORD in HKCU\Software\Policies\Microsoft\office\14.0\outlook\PST. Surprisingly, though, for a couple users deleting the DWORD did not allow them to move items into their PSTs as expected. In fact, I also ran into the same issue myself when testing. To see what was happening, I turned to Process Monitor and captured a trace of Outlook as I attempted to move an item from my inbox to a PST. I only focused on registry operations since these settings are enforced only in the registry itself. As expected, I saw the key deleted previously being queried and NAME NOT FOUND. But, immediately after, Outlook queries another part of the registry and finds an identical DWORD:

In this query the DWORD is set to 1, disabling the ability to move or copy items into PSTs. This is a bit odd because we didn’t expect to see this DWORD exist anywhere else besides in HKCU\Software\Policies…

Deleting the other instance of the DWORD would be enough to resolve but there is actually a different lesson to be learned here: sometimes it better to modify than to delete when it comes to the registry since HKCU\Software\Policies\Microsoft has precedence over HKCU\Software\Microsoft\ and it would only be necessary to change the value to 0 for the DWORD inside the policies key.