When you promote a server to a DC, and it's the first DC in a new domain, any existing local accounts on that server are migrated into AD and their filesystem permissions will be migrated as well - But the SID will change, and the domain prefix will change, so in many cases the drive will need to be re-mapped with domain-specific creds. (Ex: "domain\username" instead of simply "username")
When you join client machines to a domain and authenticate with newly created domain user accounts, the users' profiles will change (ie their Desktop, Documents, Favorites, etc will all start from fresh). You will see in C:\Users your existing local PC accounts will be like "username" and the new ones will be like "username.DOMAIN" if the username is the same. So all their stuff will still be on-disk, but not migrated to the new profile.
The process from the users' perspective will look like this: First sign-on after joining the domain. Let's say the user used to sign in with "localuser":
First sign-on, they need to click "Other User", then it will direct them to a domain sign-on (in my case, my domain is called NEXUS). Then they type in their new domain username you give them, their default password, then click the arrow:
Once this is done, they will be presented with a completely fresh desktop, Documents, etc. You can map drives automatically via GPO, but they will only fully map on the 2nd logon to the domain.
In the case above, the local username and domain username are different, so you'd have C:\Users\localuser and C:\Users\myDomainUsername for the old and new profiles respectively.
So if you create domain user accounts for everyone, (ex. Alice, Bob, Mary) - After joining their PC to the domain, and they sign in, you can deploy a script/preference to give them permissions to their previous profile to manually migrate stuff. There is a way to migrate whole profiles but this is hard and full of problems.
Being a DC, SMB signing will also be enabled for lower SMB protocols, which may affect share performance and CPU load depending on your clients and workload.
But I would like to know - Your reason for implementing AD is patching? But AD doesn't really help you with that. Do you want to deploy WSUS? That is probably not what you want. Here's why:
When you have your PCs connect to MS Update on their own, and you enable updating all MS products, all potential updates will be available to them. But when you deploy WSUS, you need to select from a checkbox list of products and update classifications you want to be able to push. If you select all of them, you will end up with a slow, bloated WSUS database and a new product could be added at any time and you'd be missing the updates unless you update WSUS and manually go through the products and classifications checkbox lists.
And even then - You don't need AD to deploy WSUS - You can use registry edits to point PCs to your WSUS server if you really want WSUS for some reason.
Implementing AD when you don't need to or want to is going to be incredibly frustrating because it is complex. It's taken me years of working in IT and tinkering with it to really understand how little I actually know about it.
But I'm happy to help you. Good Luck!
