Windows Server 2003 & Windows 11

[Metanis]

Curiouser and curiouser . . .

I moved the BAT file to common startup rather than user startup, same issue. But, and it was a "but" I had not realized, it appears that either the message about not being able to map the network drive is spurious, or it's occurring because the attempt from "persistent" is occurring before Windows 11 is able to deal with networking.

If I wait a few moments after the error message regarding drive mapping appears, as boot progresses I see the "telltale flash" of the command prompt window running for the BAT file which issues the "net use" command again. If I open File Explorer then, the drive is mapped and functioning perfectly. At the same time, the icon that shows the problem persists for quite a while after that, even when all is fat and happy.

I also discovered that the /savecred and /persistent:yes switches conflict with each other. The /persistent:yes switch results in a successful connection again (along with the login credentials, of course) but /savecred doesn't.

This is just freakin' bizarre, as far as I'm concerned. But at least there is now access to the server drive from this machine. When it's time to set up the next CAD workstation, I'm sticking to using the owner's personal MS account to link to. I don't want to have to go through this crap again, and the other machines where I used that method allowed me to enter userid/password credentials and check the "remember" checkbox for the server connection and have been perfectly happy ever since!

I've run into this in the past. As I recall it has something to do with the "scope" of a CMD or BAT file during boot. It has to be "global" so the mapping doesn't just disappear as soon as the batch file ends.

I think I worked around this by creating a shortcut to the batch file. Then I was able to use the compatibility settings for the shortcut to Always Run As Administrator. But my memory is hazy.

Then just to muddy the waters, you could also use GPEDIT.MSC on a Pro machine and explicitly define a login script file. This would be your existing batch file that you add to C:\Windows\System32\GroupPolicy\User\Scripts\Logon and define a policy object at Local Computer Policy\User Configuration\Windows Settings\Scripts.

Another trick is to use Task Scheduler and trigger the batch file to run 1 minute after boot. By then the network processes have all stabilized. Again, you would want to run it as administrator.

 

[britechguy]

Another trick is to use Task Scheduler and trigger the batch file to run 1 minute after boot. By then the network processes have all stabilized. Again, you would want to run it as administrator.

Thanks for all the info. I might try this in particular.

I really, really hate spurious error messages, and while it may not be actually spurious at the moment it's issued, by the time the user has control of the desktop the problem has been rectified.

I'm just thankful that one can use the "net use" command, as I can find abso-friggin-loutely no way to get this to work via the Win11 UI as things stand with that machine as it was set up. On the two machines that used the personal MS account as the link-to for the user account, when you first try to access the server you're presented with a classic login/password dialog with the "remember" checkbox, and away you go, and just keep on going. Under whatever's happened by using a work/school account, I am only being given the option of using an email ID as the login ID and it constantly wants either a PIN or password for it. But there is no such thing as an e-mail address style login ID under Windows Server 2003, nor PIN as we know it, either. In-friggin-sane!

 

[Metanis]

In-friggin-sane!

Is this what happens you use File Explorer on the client and attempt to connect to \\file_server\share_name ?

On my Win11 Pro machine I get a user authentication popup that allows me to type in file_server\user_name (where that user_name is one that is defined directly on the file server) in one field and then that user's password along with a check box to Save the credentials.

I'm currently logged into my Win11 box with a Personal Microsoft account.

 

[britechguy]

@Metanis,

It has not mattered. I get the same behavior as you do if I'm using a Win11 User Account that's linked to a Personal MS Account.

It's entirely different when a Work/School account with AzureAD is involved. More's the pity.

 

[Metanis]

@Metanis,

It has not mattered. I get the same behavior as you do if I'm using a Win11 User Account that's linked to a Personal MS Account.

It's entirely different when a Work/School account with AzureAD is involved. More's the pity.

I can only assume the initial login to AzureAD caused some GPOs to be activated which is blocking local SMB authentications. You could try to clear all GPOs on the machine but more realistically you should just do a Windows reset and start over.

How to reset all Local Group Policy settings to default in Windows 11/10

Learn how to reset all Group Policy Objects and Settings to default in Windows. You may need to restore default settings if things have gone wrong.

www.thewindowsclub.com

 

[britechguy]

You could try to clear all GPOs on the machine but more realistically you should just do a Windows reset and start over.

The problem being, I suspect that precisely the same thing would occur IF I used the work account, which is what I should be using in theory.

Right now the machine is in the owner's hands and going through its initial trials. If the connection to the server proves to be unstable then I will likely resort to a N&P and start all over again using the personal MS account to link to the Win11 user account again. But if I do that, it's going to be on my dime, as I cannot in good conscience bill a client for a mess like this one which should NEVER have occurred in the first place. It should have been just as easy to make this work regardless of the TYPE of MS account I used to link with the Win11 user account. Who'd have thunk it?!

 

[Sky-Knight]

I go back to the client site in about an hour. I will be running the following command, using the appropriate credentials, in hopes that this solves the issue on "the cranky box:"

net use y: \\yserver\thingshared /user:XXXX PWD /persistent:yes /savecred

I want the credentials saved so this is "automagically reconnected" each and every time the machine reboots and without the need to reenter the user name or password.

[Addendum: You are correct that the workstation is not local (or otherwise) domain joined.]

The command I gave you does all that you want, no logon script required. net use letter: \\server\share /persistent:yes /user:username password

The only thing you have to remember is to ensure the /user switch is AT THE END. If that's not the final parameter things get wonky.

 

[britechguy]

The only thing you have to remember is to ensure the /user switch is AT THE END. If that's not the final parameter things get wonky.

Well, I'll certainly try it again when I'm next out there, and I don't doubt what you're saying. It does not, however, comport with the official documentation (or even some Microsoft examples) but I long ago learned that "the documentation is incomplete."

For the time being, a script is in place and is working for the intended purpose. I'd be thrilled if that spurious warning were to somehow just vanish and I could nuke the script and have it all just work.

 

[YeOldeStonecat]

I don't have answers for you here...but out of curiosity..I suppose I'm curious what the outcome will be.

Re: Windows Pro ....when running in "workgroup mode"...which I'm assuming the 2k3 server is just running in workgroup mode. It's not set up as a "domain controller"? If just workgroup mode, having user accounts on the server that match local users on the workstations/laptops...where the account username and password are the same.

If the computer has a Microsoft 365 "business "account tied with it...is the computer "Azure Registered"....or "AzureAD Joined"? There's a big difference. If it's Azure registered, the computer should log in with a local user account. If it's AzureAD joined...it should log in with the users 365 email address. And probably has Hello taking over the login with a PIN (but you can choose to bypass that and log in with the regular 365 password). And Windows will remember that login method the next time it logs in.

If the computer is only "registered" to 365 business, the SMB access will be to the local user account. Only if it's joined to AzureAD and logging in as the 365 user will AzureAD manage the SMB access. In order to browse to local network devices, such as servers, those either have to also be AzureAD joined, or...have the AzureAD Connector running to "sync" accounts and computers tween the on prem active directory..and 365.

But...you need a much more modern version of Windows Server to run the connector, 2003 won't let it install or know how to speak that language.

We still have an on prem domain controller, there's nothing left on it that I need since we moved our data to 365 eons ago, and my computers are all AzureAD joined. But for giggles I went to browse to our old DC, got challenged to log in, I sidestepped my Hello PIN and chose another way, my old "DA\BMayo" domain user credentials and password..and I got it to see the old server shares.

 

[Sky-Knight]

Azure AD Connect is also a ring zero risk for the Azure AD fabric and shouldn't be running on anything that's in active production for any purpose other than to execute Azure AD Connect, on a machine that's isolated into its own VLAN with just enough firewall access for patches, access to Active Directory and Internet access for Azure AD.

AD itself is extremely weak thanks to Microsoft never bothering to salt anything, so all you have to do to own AD is get metasploit onto a domain member machine. It'll do a hash dump of passwords, and those can be used to access the DC and achieve domain admin. If that DC has access to the machine that has AD Connect all they have to do is pull the creds from it and BOOM Global Admin.

This entire attach chain is well documented, and automated. Do not put Azure AD Connect onto production systems as typically seen in an SMB unless you wish to enable the lateral spread to your entire cloud fabric.

 

[britechguy]

The command I gave you does all that you want, no logon script required. net use letter: \\server\share /persistent:yes /user:username password

The only thing you have to remember is to ensure the /user switch is AT THE END. If that's not the final parameter things get wonky.

Well, it didn't work any differently than before. Note that I did a net user {drive letter:} /delete command prior to any attempt to reestablish a connection so things were clean.

If I use the command, exactly as specified, invariably when the machine reboots, prior to the icon even for Windows Defender showing up in the system tray, I would get an error message that a connection could not be established. If I re-ran the command, whether via Command Prompt or using a BAT file in startup, the connection would reestablish.

My only conclusion, after multiple tries with this and using the persistent:yes option is that when the machine was booting up, it was always trying to reestablish this network connection ahead of some component that was necessary to do so being up and running. In 100% of the variations where the persistent:yes option was used this error message would occur, and unless the commands were run after that, regardless of method, there would be no connection to the server.

In the end, what did work and eliminate the error message at boot was:
1. Using persistent:no
2. Using a BAT file in common startup that runs the net use command exactly as @Sky-Knight specified except for changing persistent to no.

It's working like a charm now, with the two network shares being mapped to drive letters and with no "can't connect" messages coming up very early in the boot process almost immediately after the Windows desktop appears, and before the taskbar has even populated completely.

I suspect that something related to the persistent:yes option employs asynchronous execution and that when it's been given it's initial go ahead that something else it depends upon just isn't there yet.

 

[Sky-Knight]

persistent:yes saves the creds and configures the mapped drive in the user context automatically on the next reboot.

And yes, some NICs especially wireless ones take a bit to get online and cause this chain of events. The fix is exactly as you've done, persistent:no, and a login script firing from somewhere.

 

[britechguy]

some NICs especially wireless ones

And right now, we are using WiFi. Once the machine is placed on its permanent desk, it will have ethernet, but not until then.

In any case, I'd rather have a solution that works for either case, as it is within the realm of possibility that the whole place could eventually reshuffle space and drop all wired connectivity altogether. It's a small business of less than 10 people, so WiFi only is practical should they choose to go that route.

 

[Sky-Knight]

Usually the persistent:yes just makes a drive entry in my computer that when it isn't connected, has a red X on it.

Clicking it will force a reconnect and that usually works.

But I haven't had reason to do this on Windows 11 yet nor on any AzureAD joined machines.

 

[britechguy]

Usually the persistent:yes just makes a drive entry in my computer that when it isn't connected, has a red X on it.

Clicking it will force a reconnect and that usually works.

The first part was exactly what happened. The second, was not.

 

[Sky-Knight]

The first part was exactly what happened. The second, was not.

Fascinating, I'm not sure if that's an SMBv1 protection, or an artifact of the AAD subordination. I'll have to lab that a bit.

Though I will have a chuckle at ye old net use in a logon script trick that's been a thing for 30 years is still alive and well.

 

[britechguy]

Though I will have a chuckle at yet old net use in a logon script trick that's been a thing for 30 years is still alive and well.

Yet another illustration of what I often say: There is very, very little in this business that is revolutionary. At best it's evolutionary and a new twist on a very well worn theme.

And these sorts of things fall into the category of: If it ain't broke, don't fix it.

One does what needs to be done, in the context it's occurring, to achieve the desired ends. That often involves compromises one wishes one were not forced to make, but reality intervenes.

 

[britechguy]

I am circling back to this issue, as it has remained a thorn in my side with the one, and only one, of the three machines that I set up, and that I set up initially using a business MS Account rather than a personal one. There is a 4th machine, still in box, and I am seriously considering setting it up either with the same personal MS Account I used for the other two, or with a local account initially that I then link to the business account after I have the machine "talking to" the WinServer 2003.

This whole job has taken so much longer than I ever expected, and the client has been just wonderful as he's been sitting right next to me as I peel the layers away from the existing "tech onion" and am discovering and excising the rotten layers.

Now that we have "the complicating factor" of custom nameservers being in use for his email, as well as the still as yet not defederated GoDaddy M365 tenant, I'm trying to decide if getting him access to that WinServer from his own computer (which is the one where the network connections as far as drive mapping remain stubbornly problematic) would be best achieved by setting up a fresh one using a method I know to have worked, since I also know what else needs to be installed on it (and can be much faster in getting that done the second time around).

I am finding out the hard way (and, yes, I am still trying to follow the advice I've been given here, it's just proceeding slowly, caution is needed) just how awful it is to try to do anything with a GoDaddy federated M365 tenant. They cut off your access to virtually everything I've seen when working with others with non-GoDaddy tenants. This is what's really slowing down "the final step" of getting that WinServer content into the cloud and accessed from there.

 

[Sky-Knight]

Working with GoDaddy's M365 is the single largest mistake any small business owner can make in their technology pathway.