TrialandError

Insider builds and any builds not known to your site will show up as Other. I have several computers running Win10 1703 (build 15063.332) that are showing as Other in my dashboard as well. Once I read this article from Jason Sandy's I gave up on the Servicing Dashboard and used Upgrade Task Sequences instead. Either way it would be nice to get accurate data and to be able to click on the rings to see which systems are being inventoried.

IIRC the 1355 error means the domain couldn't be found or contacted. Did you put the FQDN of the domain in the domain join step? I've also ran into an issue where the nic wasn't grabbing an IP quick enough so the network never initialized and communication failed. We added a step in the task sequence to ping the loopback address to give the network adapter long enough to pick up an IP.

Did this issue just randomly start happening or is this the first time you have tried to deploy with PXE? Are you using DHCP options and if so what are they? Does your boot image architecture match the OS your are deploying? What version of SCCM are you running? Multiple distribution points or just one? Can you image successfully with a USB drive? Without knowing any specifics or looking at any logs I would advise the following: 1. Open the DP properties, uncheck PXE and allow the removal of Windows Deployment services. 2. Remove the boot images from the DP and delete the temp directory from your DP. 3. Give it some time and reboot. 4. Recheck the PXE box. 5. Distribute your boot images back to the DP and try to PXE boot again.

The pop-up that states you need to install those updates is normal. Are you looking in the right place? Win 10 Upgrades are listed under the Windows 10 Servicing folder and not with the rest of the software updates.

Glad you are making progress! Once you get everything working you can add the reg keys to your hardware inventory and runs reports or build collections out of them.

Yes a firewall could cause this issue as seen in this post. As long as you are absolutely certain your distribution groups are set correctly and you've checked the MP logs, I would ask the network guys to dig in. Maybe install Wireshark and start logging packets.

I'm not entirely following your logic here. Are you trying to tattoo the registry with the model of the computer during the task sequence and then use that value as a condition for other steps in the task sequence? Why not just query the model via WMI and use that as a conditional statement? Either way you don't need to echo anything in your batch script. It's not like you are going to see the results on the screen. Also you're writing the value as a string so I'm not sure "greater than" will work like you want it too. Check out Jorgen's tattoo method - it works well. You can do more troubleshooting by pausing the task sequence and running these scripts manually until you get the results you are looking for. I also simplified the script you are currently trying to use though I don't think it is the best way to accomplish what you are trying to do. @echo off for /f "tokens=2* delims=E" %%f in ('WMIC ComputerSystem GET Model /value') do set "Model=%%f" if "%PROCESSOR_ARCHITECTURE%"=="AMD64" ( Set ENV=%windir%\syswow64) else ( Set ENV=%windir%\system32) %ENV%\REG.exe ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion" /v Model /t REG_SZ /d "%Model%" /f

First of all, Welcome to SCCM! Secondly, I would advise not making any changes until you get a better feel for your environment. The SCCM product team has really come a long way in the past couple of years so while I think upgrading to the latest build is a good idea I wouldn't jump in before doing my research. If your biggest need right now is getting your 2012 R2 servers managed through SCEP then check your client settings to verify that you have a computer policy deployed to these servers that manages Endpoint Protection. i'm hesitant to lead you to any one area without knowing more about your environment. Check out these guides - they really helped me when I was first getting started.

Niall, Thanks for all the awesome guides! I got around the language issue by opening the WSUS console on the SUP, deselecting all languages besides the ones I needed and then syncing updates in the SCCM console. I performed these steps before my initial sync. It's odd that all of the other SUP settings carry over to WSUS besides the languages.

I think you are getting Driver Packages and Driver Categories mixed up. Are you saying that you can still see the driver category when using the 'Auto Apply Drivers' step? If so then you can manage these (delete/rename/etc) from the console. Under Software Library, expand Operating Systems and select Drivers. On the ribbon at the top, click on Categorize and select Manage Categories. Highlight the category you no longer need and select delete. This makes sense as the "Apply Driver Package" step does not utilize categories.

0x80004005 is a generic error that can be caused by quite a number of issues. When are you getting the error? Can you post some of the logs?

I wasn't really sure what to expect so I just targeted a hand-full of computers in IT (always like to test on my co-workers ) and used client push from the new site to enroll them. There are also a couple scripts out there that will re-assign clients but the client push worked for me. All in all, it took me about 8 weeks to get fully up on the new environment. I migrated collections that had few members and software deployments that were targeted to a small number of machines. I wanted to see first hand what the client behavior was once the new policy's started applying. The cool thing is that there really isn't a true 'Go Live' in the traditional sense as both environments will be available throughout the process. I enabled distribution point sharing and was able to re-assign one of the remote distribution points to the new environment. I also set up rate limits on the new DP and distributed most of my packages in off hours so it wouldn't choke the network.

Earlier this year I completed a similar task going from a 2012 R2 hierarchy to a stand-alone Primary running CB 1607. I chose to do a side-by-side migration which resulted in zero downtime and I was able to take my time moving clients/apps/settings over. There was no impact with AD. Existing clients continued to report to the old environment until I moved them to the new one. This is one of the articles I used as a guide. https://www.systemcenterdudes.com/sccm-1511-migration/

If the NAC account turns out to be fine then check your boundaries as well. Are these the only problems you are having? Any recent network changes?

Couple things from looking at the ccm log. Either your client push account which appears to be 'SCCMCLIENT' doesn't have the appropriate access or you are having some DNS issues and SCCM cannot reach the client across the network. Also, unless this is a test environment I would start removing any domain specific information before uploading your logs.

What CM version are you running and do you have MDT integrated? There are several different options that vary in complexity.

GetDPLocations failed with error 0x80072ee7 Failed to get DP locations as the expected version from MP 'SCCM-TEST.contoso.com'. Error 0x80072ee7 Failed to get client version for sending state messages. Error 0x8004100e The client is finding the MP but is is unable to resolve the distribution point. Make sure you have defined your boundaries and that your servers have static IP's (or at least make sure DNS has accurate info). Probably need to double check your firewall settings and IIS permissions as well. I would also start using CMtrace to look at your logs as it highlights any failures and helps you troubleshoot.

Craig, I have a feeling that you are getting hit by the Customer Experience Improvement bug/feature/issue. If you are getting the error, "The user profile service service failed the logon. User profile cannot be loaded." then it is due to standard user accounts not having access to C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. You stated above that you can logon with an admin account which does have access. You should also see 1509 errors in the event logs. The easiest fix is to add a command to delete this file in your task sequence after IE 11 has been installed.

Yes it installed correctly when running as the local system account.

I am seeing this exact behavior in a 2012 R2 environment when using the .exe installer but I am not using the PSappdeploy kit. Running the script manually or as the system account works perfectly. I have tried the traditional software package and the scripted application. I can upload the logs if needed but they are pretty much the same as above.

Thanks guys - local it is!

I am preparing to migrate from an over specced 2012 R2 hierarchy to a Stand alone primary running 1602 and wanted to get some opinions\feedback from the community before I finalized anything. I am undecided on whether or not to install sql on its own server or just install it on the site server. I know best practices used to be to install sql and config manager on the same server but wasn't sure if that was still the case.

I completely understand where you are coming from. I took over an environment that only used Auto Apply drivers and didn’t even use categories to limit them. I implemented driver packages but had to have a way to let the lesser used hardware still be able to utilize the Auto Apply step. I will walkthrough what I ended up doing but you are correct, there is no good way to do this. The way I did it was a little convoluted but it worked well for what we needed. The reason it worked so well is that I could exclude one model at a time instead of having to create all my driver packages at once. I created a new group in the task sequence labeled Drivers I then create steps to install my driver packages and have corresponding WMI queries for each step. The last step is Auto Apply Device Drivers. I use the inverse of all the WMI queries that I used on the driver packages as a condition of this step. Hope this helps.

Great post Anyweb! This is pretty much exactly what we are about to do. I do have a couple questions though. 1. How does SCCM handle client updates throughout this process? We currently have it set to automatically update clients within 7 days when a new version is available so I was thinking about disabling that until I have completely upgraded. I guess I am worried about clients updating to CU5, then to R2 SP1, etc. 2. If we are already integrated with MDT, can we just update to the newest version or do we need to remove the old extensions first?

Well I think I have figured this out. It looks like the maintenance task 'Rebuild Indexes' was not actually doing anything. I disabled the task in SCCM and created a Maintenance Plan to reorganize, rebuild, and update the indexes on Site 2's database. I scheduled the task to run during off hours and made sure there were no other task scheduled to run at the same time. I also took a full DB back up and spoke with our backup engineer and asked him to run a full back up on the server prior to my maint plan kicking off. The maintenance plan ran and successfully rebuilt the indexes. 10 computers have been imaged since then and the response time on driver request is back down to below 2 minutes. I am still going to monitor the MP_drivermgr log but right now everything is working as it should. I am assuming that the DB was so fragmented that it was just taking a long time to parse for drivers. Here are some links that I read over in preparation of creating my maint plan. http://blogs.technet.com/b/smartinez/archive/2014/03/28/talking-database-in-configmgr.aspx https://stevethompsonmvp.wordpress.com/2014/05/19/powershell-sql-audit-script/ https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html