So, $software runs on a 'server' (windows client w/ file sharing to share out the db folder), and laptop client has the drive mapped and $software also installed. This is the vendor's recommended setup.
Well, when user boots up laptop and logs in, wireless isn't connected yet, no mapped drives, so when software is opened it doesn't detect the files (b/c they aren't mapped) and user can't work.
I thought I got around this by using a powershell login script to detect when the wireless connected and then map the drive, but I just followed up and she says the laptop stop working again, so I can only assume that must have broken somehow. The user starts the software manually after logging in, and I'm not going to tell her to go in My Computer and double click the Z drive to manually initiate the mapping, then start the software. Makes me look bad.
What I will be trying when I go onsite is make use of local group policy and
-Set the wireless profile for the office as a computer config, so it logs on before login
-Set the Always wait for network at computer startup and logon
group policy
-Use Group policy to set the drive mapping for the user at login
My hope is that all this is done before the desktop appears, because from a user experience standpoint if the desktop is up then everything should be ready to go.
Any other ideas, or things I've overlooked?
If the software supports
UNC paths
, you can just use those. You can also add them inNetwork Places
via Group PolicyUser Configuration \ Preferences \ Shortcuts
.Alternatively, you could have the user start the software via a PowerShell script which does the appropriate actions and/or sanity checking before starting the software.
Local group policy does not have the ability to drive map via GPP. I ended up using a powershell script that
Deletes the old mapped drive
Waits an arbitrary number of seconds for the computer to connect to the office's specific SSID, and exits if it's not connected w/in that time frame
Once the wireless is connected, it imports the user's password from a textfile (securestring of course!) and uses that combined with the hardcoded user name to map the drive.
I can easily tell the user that when this black box disappears that everything is connected. This is what I used originally that stopped working for some reason. Well, that reason was that the user changed her password. I probably should have seen that coming, but I fixed that by creating a specific resource account and giving it permission to the required shares.
84104 brought up the suggestion of using UNC paths, but when the software is installed it will only connect via a mapped drive. Also, she would get password prompted the first time she opened the software after login with that approach, since this is not a domain environment.