1

I am following a guide I've seen recommended on here for setting up home folders and drive maps for users and I am running into an issue despite the fact that I set it up exactly as illustrated here:

http://alexcomputerbubble.com/using-group-policy-preferences-gpp-to-map-user-home-drive/

I checked the event viewer during the initial logon and even though the folder gets created on the server I see an error 4098 (the group policy failed with the error code 0x80070037, the specified network resource or device is no longer available.)

After the 3rd logon the drive shows up correctly.

Looking at the comments on the blog it shows that some users have the same issue while others do not. I can’t figure out why.

I would prefer to have the home folder created via group policy as opposed to the AD profile tab that way it’s easier for the help desk to setup a new user.

Chauncy Peppertooth
  • 11
  • 2

2 Answers2

0

We had nothing but hell out of GPO and drive mapping and several other GPO issues. Yes it is powerful, flexible, and under ideal conditions breaks only slightly less frequently than one would expect, moved everything to a powershell script.

Our script auto starts on every computer, checks a network share to see if there is a newer version than local, if so copies it down and overwrites the local cached file. Then executes the local cached file. Users on network get the newest latest greatest if/when edits are made, users off network get what they last saw while on network. The script updates based on directories named the same as the groups used to assign them in the network share, and security permissions prevent people from peeking at others login scripts (In fact ABE hides them entirely, they only have access to their own, and therefore only see their own).

Having the script enumerate what groups the user is a member of is rather trivial, you can then enumerate the arrays with switch conditions and make decisions on actions to perform base don AD user groups or local user groups.

$ADSG = @() #AD-Groups
$LSG = @() #Local security groups
$WAI = whoami /groups /nh /fo csv
$WAI | %{
            $G = $_.Replace('"','').Split(',')
            if($G[0].StartsWith('DOMAIN\')) {$ADSG += $G[0].SubString(7)} else {$LSG += $G[0]}
        }

This solves a multitude of issues drive mapping and otherwise.

VPN connections re-run the script as well so the drives remap over VPN as well.

So we just use GP to push the initial sync script, badabing, done. We have had zero issues since doing it. :-) Running fine for years.

Not sayin it is the way, but it certainly a way.

Sabre
  • 425
  • 2
  • 15
0

At first, i would always try to use as little GP objects as possible - every GPO has to be checked entirely at startup/logon, so every GPO is slowing down these processes. Only use multiple GPO if there is a reason, e.g. different traget groups.

To your problem: i would say that since during the first run of the GPO, the share you want to connect does not yet exist. So i would say after the second logon at the earliest the share connection will successfuly finish.

Why it is waiting three times... You could try setting the "Process Even If The Group Policy Objects Have Not Changed" policy like described here.

Tobias
  • 1,236
  • 1
  • 13
  • 25
  • I used the two separate policies so that I can be sure the folder is being created before the drive maps since the CSE order of operations is to map drives first. I will try your suggestion and report back – Chauncy Peppertooth Mar 18 '16 at 13:53
  • Enabling the "Process Even If The Group Policy Objects Have Not Changed" setting for the Drive mapping did not make any difference. – Chauncy Peppertooth Mar 18 '16 at 15:17