Can you put the file copy in to the logon script after the drive mapping? It would still fail the first time but then should complete when run again after the mapped drive is connected.
On 17 Mar 2017, at 14:43, James Rankin <[email protected]> wrote: I did try Group Policy with the delay set to 0, but it didn’t manage to get in soon enough. However I didn’t configure any of the other settings, let me give that a try. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Stephen Gestwicki *Sent:* 17 March 2017 13:49 *To:* [email protected] *Subject:* RE: [NTSysADM] RE: Persisting access to an Azure shared folder · You can use Group Policy to change the logon script delay but that only applies to Server 2012 R2+ and Windows 8.1+. o Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure Logon Script Delay = Enabled and set to 0 minutes · You can also try having the computer always wait for the network. o Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon = Enabled · Another thing you can try is forcing each script to finish before allowing Group Policy to move on. o Computer Configuration > Policies > Administrative Templates > System > Scripts > Run startup scripts asynchronously = Disabled Those settings may give you a shot at having Group Policy run the script first but they will also slow down your logins. · I also like applying these settings to a test OU so I can see what is going on during my tests: o Computer Configuration > Policies > Administrative Templates > System > Display highly detailed status messages = Enabled o Computer Configuration > Policies > Administrative Templates > System > Scripts > Display instructions in shutdown scripts as they run = Enabled § Warning: users can close out your script before it finishes. o Computer Configuration > Policies > Administrative Templates > System > Scripts > Display instructions in startup scripts as they run = Enabled § Warning: users can close out your script before it finishes. I hope that helps. - Stephen *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *Melvin Backus *Sent:* Friday, March 17, 2017 6:37 AM *To:* [email protected] *Subject:* RE: [NTSysADM] RE: Persisting access to an Azure shared folder Given Windows post-XP tendency to delay logon scripts, etc., I would fully expect that the scheduled task route would run earlier than a logon script. Whether would run soon enough remains to be tested, but in my experience they seem to run first before anything else I’ve found. -- There are 10 kinds of people in the world... those who understand binary and those who don't. *From:* [email protected] [ mailto:[email protected] <[email protected]>] *On Behalf Of *James Rankin *Sent:* Friday, March 17, 2017 12:18 AM *To:* [email protected] *Subject:* Re: [NTSysADM] RE: Persisting access to an Azure shared folder It needs to run in the user context, so it would have to be at logon. I wonder if a task would run earlier? Could be worth a bash... Sent from my slightly schizophrenic, but rather cool, BlackBerry Android *From:* [email protected] *Sent:* 17 March 2017 12:40 a.m. *To:* [email protected] *Reply to:* [email protected] *Subject:* Re: [NTSysADM] RE: Persisting access to an Azure shared folder Scheduled task at startup? Kurt On Thu, Mar 16, 2017 at 3:48 PM, James Rankin <[email protected]> wrote: That's what I've been trying, but the net use command, when run at logon, doesn't execute early enough to get in "ahead" of the write to the share, sadly. In order to get it done for new users was the rationale around seeing if I could get it in the default profile, but unfortunately sysprep seems to remove saved passwords (although not usernames, oddly) So net use works, but somehow I need to get it to execute earlier than seems possible at the moment, hence trying to think of a different approach... Sent from my slightly schizophrenic, but rather cool, BlackBerry Android *From:* [email protected] *Sent:* 16 March 2017 10:44 p.m. *To:* [email protected] *Reply to:* [email protected] *Subject:* [NTSysADM] RE: Persisting access to an Azure shared folder I’m not saying that there isn’t a better solution… and I’d love to know one. But I’ve had people executing the “net use /persist” from a batch file (or sending around an intern to do it). *From:* [email protected] [mailto: [email protected]] *On Behalf Of *James Rankin *Sent:* Thursday, March 16, 2017 3:39 PM *To:* [email protected] *Subject:* [NTSysADM] Persisting access to an Azure shared folder I have a shared folder set up in Azure which can be mapped via SMB. You can access this by a “net use” command which specifies a username and password. However I want all of my users to be able to write out to this share, but I need the access to be available from quite early in the logon process (I’m writing some user-specific configuration files out to the share during user logon). How can I give **all** users access to this area? I thought I could use Audit Mode to create a custom default user profile that already has supplied the username and password and saved them into %LOCALAPPDATA%\Microsoft\Credentials, but set up in this way it still prompts for a username and password and henceforth the write to the Azure share fails with an Access Denied error. Any ideas? Or should I really be standing up some Windows file servers in Azure along with some proper AD authentication? All suggestions gratefully welcomed… Cheers, *James Rankin CTA ACA* *EUC Solutions Architect* Howell Technology Group *Office*: 0191 4813446 *Mobile*: 07809 668579 *Email*: [email protected] www.htguk.com | Twitter <https://twitter.com/htguk> | Linkedin <https://www.linkedin.com/in/markhtg> | Facebook <https://www.facebook.com/HTGUK> *COMPANY INFORMATION* Howell Technology Group Ltd is a limited company registered in England with registered number 5520670 and VAT registered number GB 862 666 004. Our registered office is at 2.30 One Trinity Green, Eldon Street, South Shields, Tyne & Wear, NE33 1SA *CONFIDENTIALITY NOTICE* This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. *PRIVACY POLICY * For information about how we process data and monitor communications please see our Privacy Policy. To log a ticket please follow the link. https://htguk.on.spiceworks.com/portal
