NickolajA

The whole idea with DeploymentTypes are to make sure they run based on different requirements, targeting various scenarios e.g. an installation method for App-V if the device is not the Primary Device for the user etc. If you need to chain something, you can work with dependencies instead.

I'd really suggest that you give up on using ConfigMgr for creating your Windows 10 reference image and start using MDT instead. Follow Johan's excellent guide below: http://deploymentresearch.com/Research/Post/496/Building-a-Windows-10-Reference-Image-using-MDT-2013-Update-1 By doing this, you'll not have to import the install.wim from the Windows 10 ISO, and you'll not have your issue with taking a capture. Simply put it, always use MDT for reference image creations

I'd go about this on a organizational basis in regards to what's needed and not in your company. Normally organizations never deal with the uninstall dilemma. If you're not gonna provide some sort of option for the user to uninstall an application, don't bother. But if you're looking at licensing control for expensive software, you could setup Software Metering and based of that perhaps come up with some sort of automated uninstall for those software. As per your question, I'd not go with creating uninstall for all your applications, unless you have a Help Desk team that needs access to uninstall software on computers.

That's great! Thanks for sharing your findings to the problem

That's really an odd issue indeed. On the SUP associated with the Primary Site server having the issue mentioned, is it able to fully synchronize the same software updates? Does the Software Update Groups consist of the same software updates on all of your servers? How are the SUP configured to synchronize it's update?

No that's right, it seems that I've not updated that table for the 2012 client that's not installed in C:\Windows\CCM directly.

Exactly what checkbox did you tick for "restart"?

I've noticed the same behavior at customers and even in my lab environment. It seems to be a "feature" to always get these notifications upon logon if there's any software that's made available to the device. I've not come up with a way of removing that notification, else than simply remove the deployment.

Windows PE before HDD format X:\Windows\Temp\SMSTSLog\smsts.log Windows PE after HDD format X:\SMSTSLog\smsts.log and copied to C:\_SMSTaskSequence\Logs\SMSTSLog\smsts.log Full version Windows before SCCM agent installed C:\_SMSTaskSequence\Logs\SMSTSLog\smsts.log Full version Windows after SCCM agent installed C:\Windows\system32\ccm\logs\SMSTSLog\smsts.log Full version Windows (x64) after SCCM agent installed C:\Windows\sysWOW64\ccm\logs\SMSTSLog\smsts.log After Task Sequence has finished running C:\Windows\system32\CCM\Logs\smsts.log After Task Sequence has finished running (x64) C:\Windows\SysWOW64\CCM\Logs\smsts.log Here's a good chart describing where the active log file that's currently in used during various phases through the deployment. Just to give you a more detailed overview for Nialls question. Edit: Sorry, the table that I pasted wasn't formatted correctly it appears.

I'm not aware of any easy method for this. Instead, have a look at the Replace scenario where you simply leverage the USMT tools in your task sequence to save the user state. And when the SSD have been put in the machine, you deploy the OS again with another task sequence that will essentially restore the user data and settings. The process you're describing sounds like the old method of "ghosting" a machine.

Yes, CNAME. I've seen that error sometimes when some of the Windows Features where not installed. Please run my ConfigMgr Prerequisites Tool 1.4.1 to let it enumerate through the features to see if all the required ones have been installed. Regards,

I know it's not a solution for your problem, but I'd seriously consider changing to MDT to create your reference images for ConfigMgr. It's much more stable and works all the time (assuming you have the config set correctly of course). I created a tool last year that will easily install and configure MDT on a member server, so that it's ready for creating reference images. Take a look at this: http://www.scconfigmgr.com/2014/09/13/mdt-factory-tool-version-1-0-1-has-been-released/ Regards,

Hehe, we all make mistakes. That script that you're pointing to (that I wrote a while back) should always be used before the Setup Windows and ConfigMgr step, since that's when the OSDComputerName variable is written to the unattend.xml that ConfigMgr creates.

Even though it states and Internet FQDN, you'll have to configure that for the Site System role. You could simply just trick it to believe that it's on the internet by adding e.g. externalEP.yourdomain.com on the Site System role. Whatever you enter, you'll have to configure the certificate to include both the internal and external FQDN's. Let's say that you have your Enrollment Point installed on a server called EP01. In your internal DNS zone, configure the following: internalEP.yourdomain.com --> EP01.yourdomain.com externalEP.yourdomain.com --> EP01.yourdomain.com Then add both the FQDN's above as SAN's in your certificate. Regards,

Why go through the hassle of downloading each driver from Dell's website, that makes no sense Visit Dell Command and download the CAB-files for the models you're using in your environment: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-driver-cab-files-for-enterprise-client-os-deployment To make sure that you've not clogged your WinPE image, create a new Boot Image in ConfigMgr and add only the drivers from the WinPE 5.0 CAB-file as HappySCCM linked to. Regards,

How did you enroll the SSL certificate? Did you follow the guide on TechNet for creating a certificate template? Have a look at this: Deploying the Web Server Certificate for Site Systems that Run IIS https://technet.microsoft.com/en-us/library/gg682023.aspx?f=255&MSPPError=-2147217396#BKMK_clientdistributionpoint2008_cm2012 What SAN (Subject Alternative Names as DNS) did you include? Regards,

If you've installed the test SQL Server with a named instance and not the default, you need to run this command line instead: setup.exe /testdbupgrade <instance>\<database> E.g. setup.exe /testdbupgrade CM12\CM_P01 Documented here: http://technet.microsoft.com/library/gg712320.aspx#BKMK_CommandLineOptions

Take a look here: http://technet.microsoft.com/en-us/library/bb932135.aspx And go down to where the log file names begin with "smp". I'd go though these log files and look for any particular error. Have you checked if any more components under "System Status - Site status - Your site - Component Status" are showing errors? Edit: The information message only gives you a hint that's something is wrong with the SMS_STATE_MIGRATION_POINT component.

You'll find them on the primary site server located under C:\Program Files (x86)\Microsoft Configuration Manager\Logs (this is from a Win2K8R2 machine).

I may be out on thin ice, but did the mpMSI.log put something like this: Windows Installer installed the product. Product Name: SMS Management Point. Product Version: 4.00.6487.2000. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0. almost in the end of the log? How about MPSetup.log? Did it end with "Installation was successfull"?

In regards to the SMS_MP_CONTROL_MANAGER event log entry, I've had the same issue on my primary site server and on one secondary site server. I verified that all the SPNs where in the DNS and couldn't come up with any better solution than to reinstall the MP system role. This took a while to complete, but it in the end solved that problem. I hope this helps you on the way to solve the problems.

Hey, Did you create a task sequence and advertised it?