How do Environment Variables work with a Domain?

[Vitalius]

Hi guys,

So we are testing out domain logins for our users. Well, their domain name == their local user name. So when they log into the computer & domain, the folder under C:\Users is this: jdoe.DOMAIN because there's already a jdoe for the local account.

My question is: Does the environment variable %USERNAME% include that Domain?

So say I said to create a folder in the C:\Users\%USERNAME%\Documents directory, would that end up being C:\Users\jdoe\Documents or C:\Users\jdoe.DOMAIN\Documents?

I'm assuming the former which explains why folder creation isn't working. Would %USERPROFILE% bypass this, such as %USERPROFILE%\Documents? 

Any help is appreciated, thanks.

[RH00D]

I'm not sure of the answer, but there should be no need for end users to have local accounts regardless. Each system will have a local account such as Administrator, but all your users should only have domain accounts.

 

That is unless they had local accounts previously and you are transferring them into a domain configuration. If that were the case, I suppose you could delete all unnecessary local accounts and leave them only with a domain account.

 

*Disclaimer: Don't delete anything unless you have a backup.

[peaking duck]

the %username% token corresponds to the users username.. which is just the prefix of the Full Domain username

[Vitalius]

the %username% token corresponds to the users username.. which is just the prefix of the Full Domain username

Thank you. I figured as much. 

Is there a default environment variable to includes both the username and domain? 

So maybe something like %USERDOMAIN% == "jdoe.DOMAIN"

[peaking duck]

there probably is, but i think that it will deviate too far from your cause.

 

may i suggest to take a step back and plan your active directory carefully, including domain and local user accounts.

[Vitalius]

there probably is, but i think that it will deviate too far from your cause.

 

may i suggest to take a step back and plan your active directory carefully, including domain and local user accounts.

Little late for that. The Domain has existed for years. The local accounts have as well. 

Changing things without good reason isn't going to happen. And when I say "good reason", I mean "we literally can't function unless this change happens" kind of good reason.

Thank you for the advice though. I'd love to do it that way, but we are a small business who are just getting into what Active Directory and a Domain can actually do. We have no test environment or the money to pay for the hardware needed for one, and we don't have the time to build one in VM's on top of deploying things and fixing user issues. 

I know. It's sad. 

Basically, our current situation is all of our employees using local accounts on their machines with domain accounts being used to access databases, shares, and things like that. Our goal is to switch them over to domain accounts purely so they can use Roaming Profiles and we can control what is on their machines (Group Policies and such). 

Right now I'm testing that by just applying the GPO's and using my domain account. Since they don't log into their machines (which most aren't even on the domain anyway) as domain users, it doesn't affect anyone but me, my supervisor and the admin account (which I quickly realized was not something you want to roam, ever).

It's a slightly complicated situation. I'm doing this. My supervisor is working on setting up more backups (we have some, but we want more copies) using stuff like Dell's AppAssure and a FreeNAS server, and on top of all that, we have to make sure the normal users can work. 

And anything that changes that my supervisor doesn't understand must be immediately reverted if an issue occurs with the users regardless of whether or not it makes logical sense to have affected them. Example: FreeNAS server must be off if it's trying to be a master browser in it's own workgroup (which is it's own workgroup, as it's alone in it) if the FQDN's aren't resolving to the correct IP's. 

Makes no sense to me, but ok. Maybe I'm the one who doesn't understand what's going on, but I doubt it.

[peaking duck]

hmmmm sounds like a situation i see quite often in my professional career - a simple workgroup with AD role active on the server for no good reason.

 

if the local profile issue is something you just want to overcome so you can sleep easy at night, you could do the following;

 

*Create a Test Employee.  call it test1

Add test1 to any security groups, OU's, applicable.

Log into any workstation when its available. test functionality.

Document the successful steps.

 

* Roll your employees on to the domain one-by-one... maybe one per day

say there's an employee named John Smith and their local account is "john Smith". create a new account on the AD with the username jsmith (the full name jsmith@Domain16.local will auto complete)

set a temporary password, or better yet use Johns current password if you can to avoid alienating John from the norm

Log into Johns regular workstation at least once

Copy Johns Local Profile and chuck it into his roaming profile on your fileserver (my documents, Desktop, Favourites etc etc)

Log into Johns new Domain Profile and see the results. fine tune the process to meet your requirements

Document the successful steps.

 

Review the documented steps from the two points above..
deliberate with your boss and come up with a deployment strategy

steps should be repeatable and routine. identify cases that deviate from the routine such as the admin accounts, CEO, Directors, etc etc

 

Carry out steps for each employee

 

** Dirty Tip

Create a Security Group called "ALL Staff"

Create a new GPO. One that makes the logged on user a Local Admin.

activate/deactive the GPO when you need.. makes admin so much easier by giving the logged on User Admin Rights to the Local machine

[Vitalius]

Thanks.

The purpose of the AD role is to make giving permissions for a file server easier to apply (i.e. file server is part of the domain and we apply it based on groups). We also have a SQL database, a website (i.e. www.business.com) and some other things that depend on specific DNS settings and redirections to work correctly. So I do agree it was added when it wasn't needed, but it would make our department's (IT) life a lot easier if it would work correctly and was used fully. Which is what we are working towards.

Yes, I have been testing that with one of our employees who has a low work load (so if I take up some of her time, she is fine with it). So far, many of the GPO settings I have set are working correctly for her. 

These are the issues I'm currently hitting: 

1. Folder Redirection and Roaming Profiles
   
   Basically, there are 2 things to mess with for moving a profile's files/folders. The Folder Redirection under GPO> User Configuration> Windows Settings> Folder Redirection. And then there is the Profile location setting under Active Directory Users and Groups> User> Properties> Profile> Profile Path. 
   
   I have both set for the same location but only because I'm not sure which I should be using. TechNet tells me they are different and should point to different locations, but I tried that and it didn't work correctly. 
   
   I have the User Account Folders (where I store the Profiles and Redirected Folders) set up like so: \\FileServer\User Account Folders$\Department\%USERNAME%
   
   However, for some reason, the folders are appearing both at: \\FileServer\User Account Folders$\ & at: \\FileServer\User Account Folders$\Department.
   
   So there are two copies for some reason. But everywhere you can put the path, it is to the Departments subfoler. So I'm just confused on that.
   
   Basically, I want their profiles to be able to Roam and I want their file to be stored on the file server and synced to their machine. This way we have backups and they can login to other computers as they wish.
    
2. ODBC (Data Sources) won't load properly.
   
   I'm not sure why on this. I think I'm going to have to just upload a Regedit file to have those apply correctly as it is rather than using the Data Source option in the GPO. Not sure if that's important, but oh well. I would just prefer it to work correctly (i.e. use Data Sources and not force me to use Regedit).

So 2 isn't much of an issue since I can just use the registry option in the GPO. It's 1 that is messing me up and I'm willing to bet it's because I'm directing them both to the same location. However, I don't understand the result of having 2 different profile folders in 2 different locations when I direct them both to the same one.

Edit:

After reading an article about Profiles and Folder Redirection, I know understand the different between setting a Profile path under User Properties in AD Users and Computers, and setting Folder Redirection in GPOs. 

Now let's see if this gets fixed .

[peaking duck]

I understand that you want to have a users environment (look and feel) travel with them no matter the machine they use,

but do take the time to read up on Folder Redirection and Roaming Profiles.

Their outcomes are similar but there are slight differences and their execution is different too

 

sometimes a business has an application doesnt want to work with roaming profiles such as those that need access to c:\users\appdata\local

[Vitalius]

I understand that you want to have a users environment (look and feel) travel with them no matter the machine they use,

but do take the time to read up on Folder Redirection and Roaming Profiles.

Their outcomes are similar but there are slight differences and their execution is different too

 

sometimes a business has an application doesnt want to work with roaming profiles such as those that need access to c:\users\appdata\local

I did. Thanks. TechNet recommends using them both (and directing them to two different folders) when the User's data is large, so I'm probably gonna be doing that. 

True. I don't believe we use anything like that as I have never needed to touch those types of things. I've only ever had to fix things regarding AppData (Roaming).

Yet another weird issue. I can now no longer sign into my workstation with my domain login. If I try, it logs me in to a completely black screen, aside from the mouse, then immediately logs me out again. 

However, I can sign in just fine on other workstations. The Group Policy is updated on both using gpupdate.exe and I deleted my profile from both before trying it again.  Bizarre. More tinkering is necessary.

 

I fixed it by deleting both the Profile and Folder Redirection folders on the File Server, then deleting the profile on the workstation, then logging back in. Weird. But ok.

[peaking duck]

the joys of IT Administration.. hahaha