NickolajA

I'm not sure why you're not considering doing a side-by-side migration. It's the best and most simple option for you. There are so much content on how to do it out there.

You'd have to do a lot of scripting, have a look at the following way of accessing the variables in the TS environment: http://powershelldistrict.com/how-to-read-and-write-sccm-task-sequence-variables-with-powershell/

Regarding the GPO, you should not have that configured where it defines the location of the server. All that you should configure in the GPO is to Disable "Configure Automatic Updates". I'd attempt the following: 1. Make sure that you SUP is functioning correctly by checking it's component state in the ConfigMgr console. 2. Deploy a Software Update Group containing updates that you're sure that the reference image used in your task sequence does not include, to the OSD staging collection (where you've added the device for it to be able to start the OSD, or if you're using Unknown computer support, deploy it against 'All Unknown Computers') 3. Remove your scan-steps, these are not necessary. Only include a single 'Install Software Updates' step. 4. Check to see if any updates were installed.

The DISM.log is located in C:\Windows\Logs\DISM. You could try to run a Site reset, to reset the permissions and registry values back to default. Although I'd recommend that you check the documentation for a Site reset so that you're aware of what tasks are performed.

You should never use the Auto APply functionaly for applying drivers, that's basically a best practice in the community. Driver Packages are proven to work best in almost all scenarios if they've been created with care.

I'd just keep an eye on the different components to see if they start to report any issues, if not I'd assume you're good to go.

Instead of guessing here, have you examined the smsts.log file for the reason it's failing?

You could essentially remove the WIM file from the content source after you've distributed it, but I'd not recommend it due to the fact that your OS Image in ConfigMgr will point to an invalid file that's no longer there. Also, if you're running low on disk space, why not add more space?

Have you examined the ServiceWindowManager.log file?

Try setting the start time of the deployment 3 hours back or so, and see if it works then.

If you are going to restore the site server, change the content source with my tool mentioned by Peter and make sure that you set up a DFS namespace. Then you wont have to deal with that in the future.

Have you checked the DISM.log file when that error occurs?

Looks right to my eyes, how about the oobeSystem phase?

Have you verified that both Boot Images are present in the RemoteInstall folder on the DP server? Do you see anything special in SMSPXE.log?

Could you upload the log here so that we could take a look at the PkgXferMgr.log file?

How did you determine that the "full package" was sent to the DP?

Here are some high-level steps that I always performs for a new install: - Create volumes for best performance in ConfigMgr, including the following volumes: - OS - Program Files (for SQL instance and ConfigMgr installation) - Content Source (for all content including WSUS) - SQL Database - SQL Logs - SQL TempDB - Install SQL Server with latest supported Service Pack and Cumulative Update for ConfigMgr on the same box that will host the Primary Site - Configure SQL according to best practice for ConfigMgr, pre-create the ConfigMgr database and split it into the same amount of available vCPU's - Install a Primary Site

Excellent, thanks for sharing!

I agree with Garth. Having a hierarchy with CAS and several Primary Sites was never intended for DR scenarios.

I'd also use MDT for building reference images, have a look at this: http://www.scconfigmgr.com/2013/09/19/create-a-windows-8-1-enterprise-reference-image-with-mdt-2013/ Also, I created a tool that will assist in setting up configure everything required for creating reference images with MDT: http://www.scconfigmgr.com/2014/09/13/mdt-factory-tool-version-1-0-1-has-been-released/

You should never have to open the WSUS console when you're installing a Software Update point. These are the highlevel steps that you should take to install a SUP for ConfigMgr: 1. Install Windows Features for WSUS 2. Run WSUS post install 3. Install Software Update point. 4. Configmgr Software Update through the ConfigMgr console. I once wrote a guide for how to install a remote Software Update point on another server than your Primary Site server. The same principles goes for installing it locally on the Primary Site. http://www.scconfigmgr.com/2013/11/12/install-and-configure-a-remote-software-update-point-in-configmgr-2012/ Although I'd recommend that if you environment does not contain more than 25.000 clients.

You're welcome, I'm happy to see that you got it sorted

This appears when the unattend.xml contains empty or invalid rules during the Specialize step if I'm not mistaken. I've had that a few times in the past. Have a look at your unattend.xml and verify that you've provided correct values.

When you're doing OSD in ConfigMgr, during the task sequence after the Setup ConfigMgr and Windows step has executed the ConfigMgr client is in what is called Provisioning Mode. During this mode, the client is not aware of e.g. Maintenance Windows and other things. What you should do though is to install the latest CU (CU5 for 2012 R2) and incorporate that into the task sequence to get the latest client during OSD. Also, have a look at the AppEnforce.log and AppDiscovery.log files to see what's going on.

Thank you for sharing the solution to your problem!