Migrate user data lab MD 100

---

I am getting an error when trying to copy user data to the migration store on \plabmd02\

@Joseph-Licavoli,

Please verify that the scanstate.exe is located in the folder (i.e. X:\amd64) where you ran this command.

The Microsoft Kung-fu masters will be awake shortly and probably provide better troubleshooting solution. But I would start here!

@Joseph-Licavoli,

Good morning!

It looks like the command is correct, and scanstate is running. The error (code 27) is indicating the store path, the location scanstate is to save the migration data is incorrect, either the path or permissions.

I an going to launch the lab in a bit and see what I can find.

I have seen issues even when the command was correct. Are you copying and pasting the command? I would try opening a new command prompt and typing the command. I'm not sure why, but sometimes scanstate just seems to get stuck on an error, and even when you fix it, it continues to fail.

So try retyping the command and I'll get back as soon as I can with more information.

@Joseph-Licavoli ,

So I just went through the lab and it worked, but it almost got me. When I started typing the scanstate command, the path \plabdm02, I realized I hadn't started that VM. This would cause the same error you are seeing.

So before we troubleshoot any further, can you make sure plabdm02 is running?

@Mike-Rodrick

so at first i typed the command in wrong a couple times. and then i thought maybe i did something wrong so i had reset the machines and tried again. I noticed that i did have that server actually turned off so i turned it on and was still getting this error. do i need to download the USMT tool on the \plabmd02 for it to create a migration store? im pretty sure i dont, just trying to cover all my bases.

@Ronnie-Wong

Very good point sir!!

@Joseph-Licavoli ,

Nope, the share is already created, just need to make sure its powered up

@Mike-Rodrick

i have tried it two more times and i am getting the same error.

@Mike-Rodrick

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.

@Joseph-Licavoli ,

I just noticed you have a typo in the path. The path should be \plabdm02\migstore. You have \plabmd02\migstore. Try fixing that and let me know what happens.

@Mike-Rodrick

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.

@Mike-Rodrick

any other suggestions?

@Joseph-Licavoli

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.

@Mike-Rodrick

it worked. Thank you!!

Question:
what does \plabdm02 indicate in the command?

@Joseph-Licavoli ,

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.

@Mike-Rodrick

let me rephrase the question. why wouldnt we do it on the \plabdc1 server?

@Joseph-Licavoli ,

Ahh, good question. There are a couple of reasons we would not want to do it on plabdc01.

1. 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.

2. 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!