samba - Apr 2016 - Permission denied on GPT.ini (Event ID 1058)

Ok based on  the MS link. 

Have you enabled under Computer Configuration in the navigation tree on the left
side, navigate to Administrative Templates\System\Logon

Enable "Always wait for the network at computer startup and logon" 

If not done yet. 

Greetz, 

Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Sébastien Le
Ray
> Verzonden: maandag 18 april 2016 16:38
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Permission denied on GPT.ini (Event ID 1058)
> 
> 
> 
> Le 18/04/2016 15:35, L.P.H. van Belle a écrit :
> > Ok,
> >
> >
> >
> >> I don't think so, I launch gpupdate using local admin account,
so as I
> >> understand it, only computer account is used (since local admin as
no
> >> existence on the domain)
> > Why a local admin, please use a ?domain admin? ..
> 
> No incidence (since in fact interactive update always work :) )
> 
> >
> >
> >
> > Test as follow.
> >
> > Open de security tab of the GPT.INI.
> >
> > Advanced settings, last tab, effective settings,
> >
> > At objecttype, deselect all, select computer.
> >
> > Search for : COMPUTERNAME$
> >
> > It should resolve to your computer.
> >
> > Klik ok, now check the security settings again here.
> >
> > Must have at least :
> >
> > Traverse Folder / Execute file.
> >
> > List folder/ Read Data
> >
> > Read Attributes.
> >
> > Read Exended Attributes.
> >
> > Read permissions.
> >
> >
> >
> > Run :
> >
> > DEL /S /F /Q "%ALLUSERSPROFILE%\Application Data\Microsoft\Group
> Policy\History\*.*"
> >
> > gpupdate /force
> 
> This works (as usual)
> 
> > ( or reboot )
> 
> This fails
> 
> 
> Analyzing the complete boot sequence, I see several errors
> 
> DHCP starting
> DHCPv6 starting
> NETLOGON error no domain controller found
> LSASrv issue (max reference tickets exceeded)
> GPO error (failure to read GPT.INI)
> 
> It looks like this: https://support.microsoft.com/en-us/kb/2421599 but
> suggested fix doesn't make any difference.
> 
> It may be related to SSD enabled machines which boot too fast, but
> cannot remember if non-SSD ones hit the bug too
> 
> Regards
> 
> 
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Le 18/04/2016 16:45, L.P.H. van Belle a écrit :
> Ok based on  the MS link.
>
> Have you enabled under Computer Configuration in the navigation tree on the
left side, navigate to Administrative Templates\System\Logon
>
> Enable "Always wait for the network at computer startup and
logon"
>
> If not done yet.
>
> Greetz,
>
> Louis
>
Yes it is. The GpNetworkStartTimeoutPolicyValue key has been manually 
set to 120 (but this does not make any difference, moreover the 
corresponding GPO is also set)

What I cannot get is that GPO processing shouldn't start until network 
is available, so something seems to "trick" windows in believing that 
network is available (I disabled all but ethernet adapter in BIOS…)

Hi Sébastien,

This link once helped me, when some drive mappings didn't work for a 
particular user:

https://support.microsoft.com/en-us/kb/979731

I removed the xml file under:
\users\All Users\Microsoft\Group Policy\History\<GUID>\Preferences
(find the appropriate GUID in the event viewer)

Reboot, and our drive mappings were back.

Another thing that we needed to do in the past, to get some policies to 
apply, was to assign a uid/gid to workstation accounts.

I don't think these 'solutions'apply to your case, but then again...
who
knows...

MJ

On 18-4-2016 17:02, Sébastien Le Ray wrote:
>
>
> Le 18/04/2016 16:45, L.P.H. van Belle a écrit :
>> Ok based on  the MS link.
>>
>> Have you enabled under Computer Configuration in the navigation tree
>> on the left side, navigate to Administrative Templates\System\Logon
>>
>> Enable "Always wait for the network at computer startup and
logon"
>>
>> If not done yet.
>>
>> Greetz,
>>
>> Louis
>>
>
> Yes it is. The GpNetworkStartTimeoutPolicyValue key has been manually
> set to 120 (but this does not make any difference, moreover the
> corresponding GPO is also set)
>
> What I cannot get is that GPO processing shouldn't start until network
> is available, so something seems to "trick" windows in believing
that
> network is available (I disabled all but ethernet adapter in BIOS…)
>

I think I finally solved it…

This is indeed not related to Samba (I guess), and I have to say that I 
don't know if there is a proper fix

Let's recap in case someone take this in the middle of the thread :

Some machines fails to apply GPO at startup. Manual launches of gpupdate 
are successful, only boot up ones fail (that is, everything related to 
software installation or startup scripts).
Events log shows error about accessing GPT.ini (without telling what the 
error exactly is).
Manual access to said GPT.ini (either through user account or using the 
computer account), is successful

I guess this is some kind of race condition related to network 
initialisation which isn't totally finished when GPO processing starts. 
The faster the boot, the higher the risk to trigger the condition (thus 
SSD-enabled machines are good candidates). As I said in a previous mail, 
something seems to trick windows into believing that the network is 
available while it's not. And this something turns out to be… IPv6

Disabling IPv6 on the network interface solves the problem, enabling it 
triggers it.

I guess this is because IPv6 autoconfiguration is immediate (no need to 
get DHCP ack) while IPv4 needs to wait for DHCP process to finish, below 
is what I guess happens:
Standard PC
[Some boot stuff involving slow disk I/O]
IPv6 ready => network available
[Some boot stuff involving slow disk I/O]
IPv4 DHCP ACK => IPv4 available
[Some boot stuff involving slow disk I/O]
GPO processing

SSD PC
[some bot stuff invol… finished]
GPO processing waits for network
IPv6 ready => network available
GPO says "cannot read the file"
IPv4 ready => nobody cares


Note: configuring system to prefer IPv4 over IPv6 does not change 
anything (seems consistent since IPv4 is not available so cannot be 
preferred when GPO processing starts).

Thank you for your help, I hope this will help someone (if people 
encountering the same problem can test this "fix" and report back I 
would appreciate).

Regards

Hi,

How to test access with a machine account:

* Install psexec from
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
* open a cmd.cmd as administrator
* type:
   psexec -i -s cmd.exe
* In the new cmd (running as the computer account) type:

echo %username%

Now check if you can access the gpo folders.

Perhaps this way you can check / verify if machine accounts actually 
access the required files.

MJ

Sorry it has been a while, but error 87I was not near the client in
question for an extended period. I have now been by and spent a day, and
somewhat fixed the issue. How? I turned off the second DC. After
gpupdate couldn't talk to DC02, it tried DC01 and updated. It fixed
every little issue on the entire domain.

Now for the nitty-gritty. I tried using psexec as described in the
previous post and it succeeded, so both machine accounts AND user
accounts can open and read the gpt.ini file, despite the error being
logged. This is with both DCs on, before I shut the second one down.

I have a script on a cron job which runs once every 15min. It copies
over the sysvol from the primary DC and then does a sysvolreset to reset
the permissions per the second controller's IDs. I only edit group
policy on the main DC for this reason. Perhaps this is where my issue
lies? Maybe we just need DFS support or NTFRS between DCs. Either way my
suspicion is that despite the sysvolreset, something isn't right. What
are your thoughts? I am currently running on only the primary DC.

Lead IT/IS Specialist
Reach Technology FP, Inc

On 04/21/2016 11:13 AM, mj wrote:
> Hi,
> 
> How to test access with a machine account:
> 
> * Install psexec from
> http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
> * open a cmd.cmd as administrator
> * type:
>   psexec -i -s cmd.exe
> * In the new cmd (running as the computer account) type:
> 
> echo %username%
> 
> Now check if you can access the gpo folders.
> 
> Perhaps this way you can check / verify if machine accounts actually
> access the required files.
> 
> MJ
>