0

Thanks in advance for any assistance. I've been houding the internet for hours looking for answers and found many tips/items to note but nothing that has worked for me.

Setup:

  • Domain Controller = Windows 2008 R2
  • Client machine = Windows 7 Pro x64 SP1

I have a GPO that is applied to a user and 2 machines. The GPO executes 2 logon scripts.

One of the scripts is used to mount drives. It works perfectly on one client machine, but not on another, with the same user.

NOTE: This task must be accomplished with a logon script. The built in drive mount GPO has caused random credential cache loss through reboots/etc that cause my users much frustration and I've long since fought it. This logon script is working perfectly on one of my clients so I know this can be solved on the other client.

Scenario / Problem:

I can confirm the scripts execute on the clients due to gpresult /r /v output - I get a proper "last ran" timestamp for both scripts which proves they executed.

1 of the scripts works properly. It does some .reg imports and a couple other tasks.

The 2nd script is used to mount drives and does NOT work.

However, it DOES work when running the .bat manually from the user desktop. Proving the script syntax works, and the user has permissions.

Here is the script contents:

@echo off
timeout /t 3
net use * /delete /yes
timeout /t 3
net use I: \\10.10.6.13\Share0 /user:DOM\myuser F@kePass1 /p:YES
net use \\10.10.6.13\Share1 /user:DOM\myuser F@kePass1 /p:YES

Note that I've intentionally left off the drive letter for the second mount.

Some things I've tried:

  • Disabled Fast Logon: Administrative Templates\System\Logon\Always wait for the network at computer startup and logon = Enabled
  • Disabled UAC
  • Recreated the GPO
  • Put the script into an isolated GPO that only performs the script execution
  • Various "enforced" on/off variations
  • Various "timeout" settings in the script to force waits, etc.
  • Forced to "Run Logon Scripts synchronously"
  • Enabled "Run logon scripts visible" - However I don't ever see anything.

Some key items of note:

  • I can confirm the script executes on the client due to gpresult /r /v output - I get a proper "last ran" timestamp for both scripts.
  • OTHER scripts execute properly, it's only the drive mount that doesn't work.
  • Running the exact same script (.bat file) from the desktop of the logged in user will work properly.
  • The client that isn't working is a Virtual Machine, the other is a hardware desktop. I don't think that would matter. The VM is in our dedicated ESX farm that houses many other nodes on the same subnet. I know the networking config is proper on the hypervisor.
  • I'm running gpupdate /force each time I make a GPO change and ensuring it applied with gpresult /r /v - Then at least logging off and often rebooting between policy changes.

I'm thinking of perhaps landing the file on the target machines, then creating a task to run it after login. However, in order to place the file on each client, they'll need access to the share, which is what I'm trying to accomplish.

emmdee
  • 2,187
  • 12
  • 36
  • 60
  • Are you trying to connect to the share with different credentials than the user logging in? Why? – Grant Sep 16 '15 at 05:41
  • Yes. It's the main samba user everyone uses/knows. -- Is this bad practice? – emmdee Sep 16 '15 at 05:50
  • 2
    YES! Make samba accept their own domain accounts. Then you can actually tell who did what on the share, control access, and as an added bonus group policy preferences for adding network drives will work great. Shared passwords like that make security a nightmare. – Grant Sep 16 '15 at 05:54
  • Thanks for that info, however the issue here is the script not applying even though it's executing at user logon. I could put any user into the script and it still wouldn't mount. Totally stumped. – emmdee Sep 16 '15 at 05:58
  • Oh sorry, I thought the issue was you wanted your network drives to mount reliably on login... – Grant Sep 16 '15 at 05:59
  • Have you tried adding something like "echo hello > %userprofile%\scriptran.txt" and checking if the file got created? – Grant Sep 16 '15 at 06:01
  • Ok I've changed the script net use command to use the user I'm logging in with. I've also set it to no user/pass and tested both - same problem. – emmdee Sep 16 '15 at 06:01
  • Thanks for the tips.... I just added the line to the end of the script... "echo hello > %userprofile%\scriptran.txt" I did a "gpupdate /force" and logged out/in. The file was created in my user profile directory. – emmdee Sep 16 '15 at 06:05
  • Grant - For some reason it was indeed the user accounts. I set permissions on my share to allow the client user (I forgot to do it) and applied GPO, mounted on reboot. If you write up an answer I'll mark it as the answer. Any ideas why this mattered on one machine but not the other? The samba admin profile doesn't exist on either machine. – emmdee Sep 16 '15 at 06:14
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/29185/discussion-between-emmdee-and-grant). – emmdee Sep 16 '15 at 10:39

1 Answers1

0

Solution Background/Info:

As Grant posted in the comments to the original question: Giving the logged in user or Group (Domain Users/etc) access to the share, and not explicitly defining the username/password in the net use command solved the problem.

This also solved the problem with the GPO drive mount. Not defining the "Log in As" field and allowing it to auto-authenticate automatically with the logged in user worked.

This DOES solve the problem, however this does not answer the root cause of why using a shared domain account as I was originally attempting did not work.

Answer Summary / Step-by-step:

  • Grant the user or group access to the share (on the file server) - I personally just allowed all "Domain Users"
  • Don't define an explicit (shared) user to access the mount with the net use command as I had originally done.

This solved the problem for both the logon script and the GPO drive mount. I ended up ditching the script and just using the GPO. Unfortunately this doesn't identify the root cause of why it failed with the explicit account in the first place.

If someone had an environment were they "had to" set it up that way, I foresee them running into much frustration.

emmdee
  • 2,187
  • 12
  • 36
  • 60