I’m migrating file services from a 32-bit Windows Server 2003 R2 machine to a Windows Server 2008 R2 machine. Following Microsoft Technet guide File Services Migration Guide, I installed the Windows Server Migration Tools on the source and destination servers, and I am attempting to use Send-SmigServerData to transfer folders.
Unfortunately, after I provide the password to Send-SmigServerData, nothing happens. The troubleshooting guide didn’t help.
When I tried to kill the PowerShell session on the source to start over, the server became very slow. When I checked Task Manager, I found wmiprvse.exe was running 95% or more. Killing that process gave me the server back. (wmiprvse is the Windows Management Instrumentation Provider Service, aka the WMI Provider Service.)
I noticed that wmiprvse starts up as soon as you provide the password to Send-SmigSeverData, hovering around 50% CPU:
It was then by accident that I discovered that if I kill wmiprvse.exe while Send-SmigServerData is running, the PowerShell cmdlet actually continues and the files are transferred successfully. Further trial and error showed that if I killed wmiprvse too fast, the applet will fail as if there were a syntax error (see red text below), but if I gave wmiprvse a while (maybe a minute) and then killed it, the applet executed, as shown when the blue and yellow progress bar appeared:
I don’t know if the wmiprvse issue is in my environment or in the Server Migration Tools, but I found myself wondering whether RoboCopy wouldn’t have done just as good a job in copying the files.
Seems as though the amount of time to wait before killing the wmiprvse processes is dependent on the amount of data you are going to send and maybe the speed of the server in question. I know a 120GB partition I was trying to move only worked after waiting over 30 minutes before killing it. It could just be random times, too, but that was my experience. Hope MS fixes this bug, it’s nasty.
I’m having this same problem. I’m trying to migrate the WSUSContent folder from a 2003 R2 64-bit server to a 2008 R2 server. I found a hotfix from microsoft but it only applies to 32-bit servers running SMS 2003 (SMS2003-SP3-KB937882-X86-ENU.exe). So needless to say it will not install because the platform is not the same.
What are other solutions to migrate data like WSUSContent? Should I just map a drive to the new destination server on the source side and use ROBOCOPY?
Is there anything send-smigserverdata does differently that Robocopy, xcopy, or heck – drag and drop can’t accomplish?
THANKS SO MUCH!
Keith, I’m afraid I don’t know the answers to your questions. I wonder if the source is protected somehow since it’s created by a system process. Maybe open up its permissions? Other than that; all I can suggest is asking on a Microsoft forum.
However, if WSUSContent is the only folder having an issue, can’t you just forget that? Won’t WSUS download and repopulate that with content as needed?
Hi Mark,
Thanks for your reply.
WSUSContent is what I am trying to copy now. According to Microsofts WSUS Migration documentation this command should work. However some people have used ROBOCOPY and I am running that now. It appears the data is copying over.
Rather than have a new WSUS server go out to the Internet and download 40+ GB of updates again, its best to do it quickly over the LAN since I already have those updates on a server that I am migrating away from.
Just curious as to why the wmiprvse.exe process hangs when trying the send-SmigServerData command. I’m not really sure what SmigServerData does differently that robocopy can’t accomplish. I’ll heed your advice and maybe checkout a Microsoft forum.
Thanks for the article… I didn’t realize it was dated awhile back, but it still helped knowing I wasn’t the only one with this issue.
Take care,
Keith
If you gain any insight on the difference between Send-SmigSeverData and RoboCopy, or figure out why it happers the wmiprvse process, post back and let us know!
Hello all
I had to do a migration from windows 2003 to Windows 2012. I had set up a testlab to test it first and run in some problems
When I executed the command, nothing happens
It just stops.
I checked to udp ports, firewalls and connectivity. I disabled the IPv6 on the Windows 2012 server and still nothing. Then I did the following:
1. install on the Windows 2003 the WMI modules and start them in the services. I read that somewhere :)
2. The source folder must be shared. I my case it wasn’t. I shared the source folder with everyone permission and the migration works :)
Well..I had run for just one time. When I tried it again, it hangs again.
Then I figured out that restarting the “windows management Instrumentation” services on the source Windows 2003 server helps to start the migration again.
I tried it again and again and it works.
hope I gave some info what you can use :)
cheers
Peter jonkers
Peter, thanks for sharing those tips!
Hello Mark, Its now Aug 2013 and the bug is still present in the code somewhere.
I to am migrating from a 32-bit Windows Server 2003 R2 machine to a Windows Server 2008 R2 machine.
I get the same stall as yourself, Keith, and Peter, after running Send-SmigServerData on the source server.
In my case I got the transfer to work by restarting the WMI service. Which appears to have the same effect as killing it.
Killing it is the way to go, and not restart, as if you do many share transfers eventually each running WMI service consumes about 25% of CPU each, eventually hangs the server.
Its a very nasty one Microsoft, appears still not fixed after 3 years?
Regards, Craig W.
Hello again, meant to say
…as if you do many share transfers eventually each running WMI process (wmiprvse.exe) consumes about 25% of CPU each, eventually hangs the server.
Me again, I should have waited until trialing a few times before posting here. I found just killing the process stopped the send. I had to still restart the wmi service to get the send working. However if dong many sends I eventully had to kill the occumulating wmiprvse.exe process’s (they just sit there on 25% CPU in the process list).
Hope this is of help to others (can be very frustrating at first). RoboCopy or RichCopy seemed a lot easier to use before this.
Regards, Craig W.