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]] 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]<mailto:[email protected]>
Sent: 17 March 2017 12:40 a.m.
To: [email protected]<mailto:[email protected]>
Reply to: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
Sent: 16 March 2017 10:44 p.m.
To: [email protected]<mailto:[email protected]>
Reply to: [email protected]<mailto:[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]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of James Rankin
Sent: Thursday, March 16, 2017 3:39 PM
To: [email protected]<mailto:[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]<mailto:[email protected]>
www.htguk.com<http://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
