Yes we did see this behaviour but to be honest that was way way back.
What happened is that the policies registry hyve was not being excluded from appstacks and writables but I'm speaking of the first version so my guess is that won't be the issue for you.
What is the message you are getting? Is your packaging machine within the domain? and does it have a GPO assigned to it? If so, do you block cmd from within a GPO that could block these features? And do all appstacks have the same behaviour? Or is it a specific appstack that is causing this?
Snapvol.cfg has expected Policies hives excluded as you suspect. Messages provided from failed RSOP/GPUPDATE are... (Again works when yanking appstacks from session).
Packaging machines are all domain joined, however we use local admin login to capture. GPOs applied to computer objects are minimal and it doesn't appear that all AppStacks are affected. We are still trying to pin down specific AppStacks but it appears to be randomized at this point.
One thing is for sure, no AppStacks means this problem doesn't occur...
I apologize for bringing that post up from dead but we are recently seeing the same problem. Right after login I can run gpupdate and gpresult with no problems and then couple of minutes later I get Access Denied on gpresult and gpupdate fails. In our case I also see that removing appstacks resolves that problem. We are also using writable volume profile only but that doesn't seem to have effect, only appstacks.
I have looked at the appstacks that I have attached and I see that they have been created 188.8.131.52U
I'm not too sure if that would be the problem since we are on AppVOlumes 2.16 and I didn't get a chance to test other appstacks created with 2.16
If I look at the snapvol.cfg GPO exclusions here is what I see related to that:
Not sure if this is how it should be or if there is something different in 2.16.
I was wondering if you were able to resolve it and if you could provide any information on it?