h4x0r

A few questions come to mind...first, if you have a single site, why are you retiring a SCCM 2012 R2 setup, only to re-install a new SCCM 2012 R2 environment with a different site code? But check out this thread https://social.technet.microsoft.com/Forums/en-US/e0a9d2c6-dd81-4d3c-8a37-52a6e1303928/reassigning-site-sccm-2012-r2?forum=configmanagergeneral

Not via standard Application and Package deployment methods (that I am aware of)...what you're talking about sounds like a pain though, because it would mean zipping up all your program installers, then creating a task sequence using "run command line" steps with the package as the source to unzip the file to a directory on the workstation, followed by another run command line step to kick off the installer from the files that have been unzipped. The problem you run into there is part of the reason CM made the move from Packages for application installation (in SCCM 2007) to their Applications model...very simply: detection methods. How do you know if the command line you just executed ACTUALLY install the software successfully? I would look at your client BITS settings and see if tweaking those helps...if it is set really low, then you might be able to open that up a little more.

Just create a collection for your workstation models (you could do a large collection for all Dell workstations, and then sub collections for specific models if you need it)...then just target that collection with your app/package

Is there a reason you don't want to use the UNC share? Next to WSUS, it is probably the easiest method for having those updates available for clients. There are scripts out there which will download the updates for you, so all you have to do is schedule the script to run on your server at set intervals.

Do you actually plan to uninstall every piece of software you deploy? If so, then maybe it is a good idea. I would be concerned about keeping track of group memberships. In our case, I only create uninstall collections on an as-needed basis...sometimes I simply deploy the uninstall directly to an existing collection (such as a lab) when I know that we will not be deploying the software in the future and need to remove it from existing workstations.

As far as AD discovery...check under Administration > Hierarchy Configuration > Discovery Methods > Active Directory System Discovery. If that is enabled, you should have an AD container setup...open the properties and see what is set under the Active Directory Discovery Account.

Glad to hear it is working That's an odd one regarding the partition name. In our TS here, the default value of "Windows" is used and I've never bothered changing it. If the partition is being named OSDisk when they are labeled something else in the parition properties, then that makes me think there's something setting that value (duh)...my first inclination would be to look at anything referencing OSDisk. Maybe it is your "Set OSDDisk Part" step underneath your "Format and Partition" steps?

Have you seen these? http://www.windows-noob.com/forums/topic/7217-client-version-50078041000-is-not-compatible-with-the-site-111-version-50077110000/?p=27712 https://social.technet.microsoft.com/Forums/en-US/855e3769-2553-4595-9e34-a341f1e34c4a/cannot-deploy-client-after-sp1-for-sccm-2012?forum=configmanagergeneral *edit The fix in the first link is also noted here as well, but i wanted to include it here as the scenario shares similarities to yours http://billbjerrum.blogspot.com/2015/07/client-version-50082391000-is-not.html

Thanks for providing that...I'm not seeing those messages about skipping those format and partition steps. Also, in regards to the article I posted...look at the "Set variable for drive letter" step in your Install group. In your log it looks like it is setting the OSDPreserveDriveLetter variable to False, which is possibly why your image is getting installed on E or D.

Yeah, I wouldn't move your SQL unless it was absolutely necessary...you mentioned wanting to move it, so I suggested moving it first and then moving CM...but really, that will just be creating more work for you.

Take a look at this article here...it isn't exacty a short read, but has a couple steps that I would start with... http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2014/04/28/how-to-ensure-that-windows-installs-on-c-during-a-system-center-2012-configuration-manager-osd-task-sequence.aspx Specifically, once you get to the "Resolution" section, look at the settings for the boot and system partitions and make sure that those are what you have in your TS. If your boot partition is pulling a drive letter, then that could be part of the problem. Steps 7 and 8 might be unnecessary, as we are installing from WIM's here, and have not needed the OSDPreserveDrive letter variable set...but I would start there by verifying that those settings are good to go. As a side note, I went back and looked at your SMSTS.log file because I was curious about your "Set OSDDisk Part" step in your TS...in your log file, it looks as though all of your Format and Partition steps were getting skipped...??? I could be wrong about what I'm seeing there, but under each section it says "The action (Format and Partition Disk...) has been skipped because the condition is evaluated to be false"...could you attach the smsts.log of your successful imaging process?

If it were me, and I was wanting to also move my SQL location to a cluster that is already setup, then I would do that first and verify that everything is good. Then run a backup, and restore on the new server. As far as your setup on the new server goes, you wouldn't need to install CM first and then restore the backup...you would do that during the install on the new server. Couple links with a quick search... http://anoopcnair.com/2012/07/01/sccm-configmgr-2012-primary-site-server-and-database-recovery-part-1/ http://blogs.technet.com/b/configurationmgr/archive/2013/04/02/how-to-move-the-configmgr-2012-site-database-to-a-new-sql-server.aspx

It may target the D drive during the installation, because the TS is going to recognize the first partition (the boot partition) as C. When the workstation finishing the imaging process, does it show C or D as the system drive?

If you double-click that partition (which is actually labeled OSDisk), you can see what variable is listed for that partition...however, you will also want to look at the "Set OSDisk Part" step, as that may be setting that variable as well (sorry, didn't look through your logs to see what that step was doing). For troubleshooting purposes, you might try disabling the "Set OSDisk Part" step (assuming it is setting the partition variable for your Apply OS step), and either set the variable on the actual partition--labeled "OSDisk (Primary)" in your Format and Partition Disk step--or set your Apply OS step to use the next available partition.

Yes. in your smsts log, it is trying to install the OS to whatever partition is set for the variable %OSDisk% and that can be set on the "Format and Partition" step. If you click on one of those steps, you'll see the different paritions listed that it will create...opening the properties for one of those partitions will list a space for what variable to use in that Apply OS step. In your case, it looks like an MDT step is setting that variable (just after the Format and Partition steps), so you might look there to verify that whatever TS variable it is using to identify the installation partition is being used in your Apply OS step (assuming you still have the "Logical drive letter stored in a variable" in use)

Looking at the smsts.log it shows that it is failing to apply the image...I don't think it is failing after it. Here's what I see: Set command line: "OSDApplyOS.exe" /image:WLH00020,2 "/config:WLH00024,unattend.xml" /target:%OSDisk% ((g_Target.Disk > 0) || (arg == L"0")) && (g_Target.Partition >= c_MinPartition), HRESULT=80070057 (e:\nts_sccm_release\sms\client\osdeployment\applyos\applyos.cpp,254) The /target parameter specifies an invalid target location. ... Failed to run the action: Apply Operating System Image. This is usually caused by a problem with the program. Please check the Microsoft Knowledge Base to determine if this is a known issue or contact Microsoft Support Services for further assistance. The parameter is incorrect. (Error: 80070057; Source: Windows) Have you verified that your disk variable in the partitioning step is correct in the Apply OS step? Have you tried using the next available partition instead of a variable?

True, but the main thing was in the opening paragraph of that section..."By default, a primary site server is configured as a distribution point. However, assign this role to a remote site system and remove it from the site server if possible." I got the feeling that the OP was looking for a current/best practice outline for DP placement, and their testing has already provided the data they need for considerations in those bullet points. I would be hesitant about the registry hacks, because you already know things are working correctly on the main campus...I would be concerned about the integrity of the data that's being sent across the WAN link, since that can be an issue when you make those registry modifications (though there are safe parameters for that, too). Putting an additional DP would be my first inclination, too...hence the initial question regarding why they hadn't yet.

You might check this out, if you haven't seen it already... https://technet.microsoft.com/en-us/library/Gg712321.aspx#BKMK_DistributionPointInfrastructure

Out of curiosity, what is keeping you from placing a DP at the remote site (aside from differing opinions)? Is it lack of a workstation/server to serve the role?

Just curious if you ever got this resolved...it is possible that on your prior models, the drivers were already included in your Windows install that was captured, hence why you might not have needed an Apply Drivers/Apply Driver Package step.

In our environment, we had issues with Java and Flash updates getting installed on a regular basis...we eventually scheduled a task sequence to run at certain times that would do a few things in addition to install the latest versions of those plugins (such as close browsers, mms.cfg, uninstall old plugins, etc). At that point, I basically just keep the application updated.

I had an issue with some of my sql log files a ways back...you've already shrunk your files, but check this out to see if it is of any help http://www.windows-noob.com/forums/index.php?/topic/6597-sccm-2012-issues-with-reportserver-logldf-size/

There is a certain level of convenience offered by the Dell driver packs, but I have always had issues with how bloated they were...hence why I try to get the drivers directly from the mfg. At this point I will probably be moving to driver deployment via Driver Package in CM.

I can confirm that using the Install Driver Package step installed the drivers. So then my questions stands...what could cause drivers to install for the Install Driver Package step, but not Auto Apply Drivers?

Wow...so scratch what I said previously...I thought applications were installing, but apparently not. I had forgotten that I had enabled apps to continue installing when there was an error, so it was just cycling through the list (I didn't think it was getting that far previously, but I was wrong apparently). BUT, this is what I get for too much multi-tasking...it actually ran the old OSD rather than my new test TS using the driver package...feeling a little like an idiot. Will test again (this time with the proper OSD TS) and report back.