Folder Redirection + UPN Suffix

[Michael]

Hello all,

 

I have a query I hope someone can tell me what I'm doing wrong -

 

I've created numerous UPN Suffixes in my test environment as follows:

 

[email protected]

[email protected]

 

I want the folder home drive to match, so their home folder in AD reads:

 

\\Server.FQDN\[email protected]$

\\Server.FQDN\[email protected]$

 

So far so good, now I proceed to Folder Redirection. I specify Basic, 'Redirect to the user's home directory' - then the same for Pictures, Music, Videos. These all redirect fine, however Favorites, Contacts and Downloads etc... do not redirect.

 

I specify:

 

\\Server.FQDN\%username%$\Favorites

 

And it doesn't work, nothing maps. Any ideas?

[Boredguy]

Could it be that those folders don't like the @ symbol in the share?

[Steve21]

When they log in are they using the full username with domain part?

 

Steve

[jaminben]

Try not making it a hidden share.

 

[url="file://\\Server.FQDN\%username%\Favorites"]\\Server.FQDN\%username%\Favorites[/url]

 

rather than

 

[url="file://\\Server.FQDN\%username%$\Favorites"]\\Server.FQDN\%username%$\Favorites[/url]

 

and see if that works first.

[Michael]

It could be it doesn't like @ but then what's the solution?

 

I've tried logging in as both with and without the domain extension, same result.

 

It just means that I can (in theory) have to people with the same name:

 

[email protected]
[email protected]

 

If their home directories have to be jjones$ then this isn't going to work.

 

I suppose one solution is a separate DFS or server instance, but again, this kind of defeats the objective.

[jaminben]

What does Event Viewer tell you on the client machine?

[Steve21]

Just don't think the way you're doing it %username% wouldn't return the entire path would it? (Guess you could try within command prompt by echo'ing %username%)

 

Have you tried just using a variable version? Like %homeshare%%homepath%\Favourites? (Homeshare being the path within AD)

 

Steve

[Michael]

Results as follows:

 

If I remove the $ sign this makes no difference. %username%$ and %username% works in a separate/live environment so I know this isn't the issue.

 

Even if I set the user as jjones with the domain's native UPN suffix, the same thing occurs, so it looks like the @ is the issue in the folder path, yet it does map Documents, Pictures, Music and Videos - just not everything else, so this rules out the likes of DNS for example.

 

Other than separate server names/ DFS instances, I can't see what other solution there is to this? Many thanks for all the suggestions.

[Michael]

Even worse (as per my example), I can't have two users with the same name, regardless of the UPN:

 

[email protected]
[email protected]

 

It won't allow it, even if I change the pre-2000 logon to something random.

[psydii]

How about having the domain name as a folder?

 

\\server\domain\samaccountname

 

 

(I saw this suggested somewhere on the interwebs)

 

 

Word of caution:

 

As you are in a multi-domain environment you are likely to need to use FQDN for accessing hosts (is that server.school1.net or server.school2.net or server.centralsite.net) but by including the domain name in the path of the folder you are creating some very deep folder names before you start (with two FQDN stings in path). You are likely to find users running into 260 Character MAXPATH limit.

Edited May 18, 2016 by psydii

[Michael]

I've tested some more as follows:

 

Creating the following two users (with the same name J Jones) works providing they're in different OUs (which is fine), I can live with that.

 

[email protected]

[email protected]

 

The issue still remains with the pre-2000 login, which it appears there's no way to switch off or remove - the only option is to input any old rubbish so long as it's unique.

 

In terms of share names, seeing as it doesn't like @ signs in the directory path (despite accepting it), the logical step is a DFS Namespace (per group of users), which also allows their data to be synchronised back centrally for backup purposes etc...

[Michael]

So in summary, you could have a name space called:

 

\\Jupiter.FQDN\share$

\\Mars.FQDN\share$

 

This would get around the issue of the share name being unique, seeing as they're hosted in different instances, yet connected to the same domain.