Migrate user data lab MD 100
-
so scanstate is loading all of kyoshidas apps and user files to a migstore in \plabmd02, correct? UI is including kyoshida and UE is excluding all other users, correct?
do i maybe need to go in and create a migstore folder in \plabmd02?
-
any other suggestions?
because i have followed every step that the lab has written on it and Md02 has USMT and all the correct files on it however i am still getting a store path error so i have no idea what could be going wrong.
-
I just noticed you have a typo in the path. The path should be \plab
dm
02\migstore. You have \plabmd
02\migstore. Try fixing that and let me know what happens. 🤞 -
My dyslexia kicked in on that one lol let me give it a shot. The good news is: i have typed it in soo much that i actually understand the syntax pretty well now. hahahah thank you so much for your guidance Mike.
-
any other suggestions?
-
Closer! This time you are missing a slash
/
in front of UE.So true, as an instructor, I actually like it when things don't go right the first time. If it had, how much would you have remembered? Troubleshooting is a great learning reinforcement tool.
-
-
Awesome, glad it worked!!
\\plabdm02\migstore
is the Universal Naming Convention (UNC) path to the shared folder where the USMT migration data is to be stored. When you run scanstate on the client, it collects the user data to be migrated, and saves it to the location specified by the UNC path. When you run loadstate, you use the UNC path to specify where to retrieve the migration data from.UNC paths follow the format
\\servername\sharename
. So this UNC path is pointing to a shared folder named migstore, that is located on a server named plabdm02.UNC paths are a standard for identifying servers, printers and other resources in a network, which originated in the Unix community.
-
let me rephrase the question. why wouldnt we do it on the \plabdc1 server?
-
Ahh, good question. There are a couple of reasons we would not want to do it on plabdc01.
-
Plabdc01 is a domain controller (DC). Because DCs host a copy of ntds.dit (the Active Directory database), there is a higher level of security. This database contains user accounts, passwords, etc. Access to the domain controller very restricted. In order to store the migration data on plabdc01, you would have to create a shared folder and give whomever was running scanstate write access to the share. Most organizations would consider this to be an unnecessary risk, and probably violate policy. The protocol for sharing folders, Server Message Block (SMB), has had many security vulnerabilities associated with it, so not something you would expose on your domain controller. A member server, file server like plabdm01 would be more suitable. Less risk if a vulnerability was exploited.
-
Scanstate is gathering user data. In the lab, it's just one user, but in a production environment, it will most likely be many users. Estimating the size of the data captured can be difficult. USMT applies compression by default which helps with the size. Normally DCs don't have multiple volumes, like a file server would. So you would most likely be storing the migration data on the C: drive. If the migration data set is large enough, it could fill the drive, and cause the DC to fail. A file server probably has volumes dedicated to file storage, other than the system drive. So if the drive fills up, USMT might fail, but not crash the server. Even if it was being stored on the system drive of a file server, if it crashes, not as bad as a DC failing.
So, to sum it up, because I talk to much, you would not want to store migration data on the DC for security reasons and storage capacity reasons.
Hope this helps!
-