Windows Homedrive - mounting fails due to delayed firewall authentication

LHerzog said:

The homedrive is a user attribute in AD, it would not be a workaround to use a start script with delay, because this would mount the share but will not set the attribute.

Can you explain what you mean by this? Particularly "but will not set the attribute".

Are you mapping the Home drive through the AD 'Home folder' attribute? Have you tried mapping it with a GPO instead?

I haven't tried this as a solution as we don't use Home folders but we do use user authentication for access to other GPO mapped drives and it works, so I don't see why the Home mapping should be any different if done by GPO.

It isn't perfect as you can't access the drives for about thirty seconds after logging on but the drives are mapped and access works fine after that.

We also get the delay logging in. Not minutes but I usually have to wait about thirty seconds after the login prompt before I try and login.

LHerzog said:

The homedrive is a user attribute in AD, it would not be a workaround to use a start script with delay, because this would mount the share but will not set the attribute.

Can you explain what you mean by this? Particularly "but will not set the attribute".

Are you mapping the Home drive through the AD 'Home folder' attribute? Have you tried mapping it with a GPO instead?

I haven't tried this as a solution as we don't use Home folders but we do use user authentication for access to other GPO mapped drives and it works, so I don't see why the Home mapping should be any different if done by GPO.

It isn't perfect as you can't access the drives for about thirty seconds after logging on but the drives are mapped and access works fine after that.

We also get the delay logging in. Not minutes but I usually have to wait about thirty seconds after the login prompt before I try and login.

JasP  it's like you said: GPO mapping of drives is no issue - they will be available after a short time and the drive is mounted.

But if you set this, it is not the same as a standard drive mount.

(screenshot taken from google)

We have apps that read the attributes here:

and want to use them.

Maybe set H: using GPO and read H: UNC-path within loginscript and write to homeDirectory Attribute?
What kind of Software uses that AD-Attribute? I'd rather look for another solution within that software.

At least as server stored userprofles getting more and more outdated and being replaced with fslogix...
I think you will not build your whole it-concept around one specific (old?) software, that uses legacy windows functions/attributes?

You can set homeDirectory yourself and use GPO to map Home drive (instead of using 'Home folder' in AD) then it should behave the same as all the other GPO mapped drives.

I set the path \\server\share\username in HomeDirectory attribute in AD without HomeDrive

Windows Client uses it in variables as:

before:
set
...
HOMEDRIVE=C:
HOMEPATH=\Users\username
...

after (only when firewall rule allows unauthenticated traffic)
set
...
HOMEDRIVE=C:
HOMEPATH=\
HOMESHARE=\\server\share\username
...

unfortunately, this is causing the same issue. When the firewall rule to the file server requires user authentication, the home share variable will not be set on the client and the user login to Windows is slow, "waiting for user profile service".

screenshot shows firewall blocking access to file server during Windows logon. And one success after the user is logged on and did a manual browse on the server file share.

So Windows seems to want to access the UNC path of HOMESHARE even when there is no need to mount it as drive.

Sophos Support has no solution currently but has filed is as Feature Request WINEP-I-293

thank you Vivek Jagad  for your confirmation today via mail