Configuration Manager 1511 adventures

Posted: February 1, 2016 in Configuration Manager, Information, System Center, Windows 10, Work in Progress

I am starting work on now upgrading have upgraded our ConfigMgr2012 R2 hierarchies to the new “Configuration Manager with no more version numbers” build 1511. There are roughly 120+ site servers in the central hierarchy (across 2 CAS hierarchies), so hopefully things go well. For the most part things went quite well, no major issues at all.

I’ll keep this page to note any special gotchas that are outside the various step-by-step guides already out there, and also some easy quick link references.

Upgrade Install guides, take your pick. There are others out there, but make sure you test first in a Lab to ensure the instructions are still correct as there may have been product changes since the guides were written

Other references

 

OS

  • No specific OS related issues (yet)

SQL

  • When performing the /testdbupgrade test the database copy must be on a separate SQL instance (or SQL server) to the current site server database. i.e. don’t mount a copy of the database in the same instance
    • Do this test! It will save a lot of potential pain
    • SQL Collation must match current SQL server
    • Mount the test DB in a Default Instance. There are some report of it working under a named instance, but many more saying it doesn’t. I couldn’t get it to work under a named instance
    • Out of 14 database I have two that are throwing errors. Looks like there is some orphaned package data in the DB causing NULL errors
  • TBC – Stop existing SQL AG mirrors prior to upgrade (we use them as read-only copies to offload reporting, not for actual Availability purposes)
    • This shouldn’t be an issue. (No issues were encountered with the AG still functioning perfectly post-upgrade)
  • If SQL is installed on a remote server/instance, make sure the installation account you are using has SYSADMIN permissions to the SQL instance. (Our SQL DBA’s insist on removing sysadmin rights from the account despite Microsoft stating it should be granted)
  • Post-install, check any SQL backups as upgrade may change SQL backup model https://technet.microsoft.com/library/mt592024.aspx
    • This was not a problem that happened for us
    • We also have our CAS SQL instances in an AG which requires “full” and may have prevented anything from changing it

Configuration Manager

  • Make sure you have downloaded the *latest* CM setup pre-req files. Microsoft may make small changes to the upgrade scripts to fix bugs. If you built your lab several months ago then check if the files have changed since
  • Windows 10 Servicing – Watch out if you start enabling the Windows 10 Servicing functions. I imagine many people will discover this “issue” when they realise they have suddenly run out of disk space! Best approach is to manually download specific Upgrades as they are identified as needed in your environment. I am testing to see if setting the evaluation schedule to “Do not run this rule automatically” is enough to stop the download. If not, then will need to “Disable” the plan To stop it downloading all the files, you need to disable the Plan completely. You can still download the “required” updates manually as needed. This is something that really needs to be improved in future updates of CM This is something that is now fixed in 1602
  • Test impact of automatic Client upgrade in very large environments (150,000+ clients)
    • This has been enabled with a 3 week window. I’ll post progress and outcomes if there is anything of note
  • Hotfix KB3127032 – Windows 10 Upgrade are not downloaded in ConfigMgr
    • Install after upgrade
    • This patch was reporting a warning in the pre-req check as it detected the “Site mode is not in read-only mode due to maintenance, recovery or upgrade.”. Investigating what this means but I suspect it wants the whole hierarchy to be in Native mode rather than the mixed mode due to the Primary sites not being upgraded yet (refer to the point further down below regarding sites not fully coming out of upgrade mode)
  • Enable WSUS cleanup wizard
    • Site component config – SUP – Supersedence Rules – Run WSUS cleanup wizard
    • If you haven’t done a cleanup for a while then a manual one might be needed first to prevent SQL timeout issues (need to write a post for quick reference)
  • Disable all backup maintenance tasks (and other tasks that might run during the backup window, or just disable them to be sure)
    • Prior to upgrade, manually start the SMS_BACKUP service to trigger a backup. When complete, rename/move the folder to a new location as a pre-upgrade archive so it doesn’t get overwritten by the next backup
  • During the setup prerequisite check it will do a WMI connection to every site system in the site for multiple checks
    • This includes remote DP servers and can take quite a long time if you have a lot of them. In my case we have around 250 DP’s on each Primary (1800+ all together) so it takes a while
    • This test failed to return the “CSDVersion” from the remote registry on the DP’s so gave a warning saying that the OS version may be unsupported. fortunately this is presented as a Warning rather than as an Error
  • After the upgrade, be patient and leave it alone for a while to get database replication under control. Don’t jump in and start changing or playing with things
    • We found it necessary to reboot all the Management Points as the MP role would not start correctly despite reporting the setup had completed successfully and no reboot was required. After the reboot the role retried/completed installation
    • An issue was encountered where every remote PxE enable DP had the PxE provider stopped during the upgrade. The WDS service was still running. This was fixed using a script to remotely restart the WDSServer service on all DP’s. This occurred on BOTH the hierarchies I updated, so I wonder if there is a bug somewhere
    • 3 of the 7 Primary sites were indicating they were still in “upgrade mode”. The console was loading properly, all services were working and SQL replication was proceeding correctly and without any errors
      • This was noticed when trying to install some of the post-upgrade hotfixes. They perform a pre-req check for the site mode and failed at that step
      • A query against the Primary database was the only indication. “Select mode from vsites” returned ‘0’ on good sites, and ‘6’ on problem sites
      • I ran Link Analyser and let it recreate the SQL broker. That may have helped but I’m not really sure. It cleared itself up after a couple of days
      • TechNet forum post for reference

WSUS

  • Hotfix KB3095113 – Enable Windows 10 Feature Upgrades
    • Install before upgrade
  • Set Language options to “English” only to reduce the number of updates that are in the catalogue and downloaded (default is for all languages)
    • WSUS console – Options – Update Files and Languages – Update Languages – Download updates only in these languages – English
    • At CAS SUP only. Downstream SUPs will inherit settings as needed

MDT

ADK

  • Use the “RTM” version of the Windows 10 ADK as there are known issues with the newer 1511 ADK build – http://blogs.technet.com/b/configmgrteam/archive/2015/11/20/issue-with-the-windows-adk-for-windows-10-version-1511.aspx
    • KB3143760 has been released to fix the issue when using ADK 1511. This fixes the issue but is not the “nicest” of patches to apply. MS should be releasing an updated version of the ADK that will handle this properly
    • The schema.dat fix needs to be applied to both ‘amd64’ and ‘x86’ WinPE images if you need both architectures
    • This fix is messy to apply, but it does work and also allows the use of the newer WinPE which fixes other issues particularly with UEFI systems
  • Any additional SMS Provider servers also need to have the ADK updated. You only need to add the Deployment Tools and WinPE parts, the USMT isn’t needed on Provider servers.

 

 

Comments
  1. Nice post.

    I am very wary of the automatic lcient upgrade “feature”. It’s caused me problems in the past:-/

  2. The FSP got hammered with client deployment failures. For some reason, it would return a scheduled upgrade as a failure to deploy which made the report very messy and difficult to deal with. I also found that any clients I had already upgraded were just scheduled to be upgraded anyway… it wasn’t “smart” enough to do an existing version check.

    Maybe things have improved though.

    • Scott says:

      My understanding is that it works by creating a scheduled task on each computer and that task is what then runs a ccmsetup upgrade check. The site server itself doesn’t attempt to determine existing client version, it relies on the ccmsetup job doing that. If it doesn’t need to update then it shouldn’t do anything.
      Did you have the “upgrade in xx days” set really low? I wonder if that could cause the storm as clients are constantly doing a client upgrade check.
      As I said, I still need to experiment before applying, and at most I would probably enable it for a week or so and then turn it off again in the event of any traffic storms.
      I don’t think the way it works has changed from when it first appeared other than working with interim versions of client updates and not just major versions.

      • Oh it wasn’t so much traffic volume over the network. What I meant was, every single scheduled client upgrade sat as a deployment failure from the point it was active until the client ran the scheduled task🙂

        Now yes, it could be unique to my environment, but it’s one of the reasons I walked awya from it.

        • Scott says:

          Quick follow up on this. Automatic client upgrade is going well. No issues noted at all. Roughly 43,000 clients upgraded so far and still going up.

        • Scott says:

          Around 120,000 client auto-upgraded now with no issues. The process seems to work but does take a while. I haven’t started looking yet to see what is holding up the remaining clients from upgrading, but we have a very “dynamic” environment and it is not unusual for machines to be off the network for long periods of time.

  3. Chris says:

    Hi Scott (or anyone else that has had experience with the Automatic Update Feature),

    I had a few questions:

    1. From your experience, does the client upgrade process require a reboot? From what I read, it doesn’t appear so, but any additional confirmation would ease my concern.

    2. I would imagine that since “upgrade” is in the name of the feature, the feature doesn’t perform a fresh client installation on existing machines detected in the targeted collection. Is this correct?

    3. Would you happen to know what specific collection is targeted when this feature is used?

    Thank you for the post and for the additional help!

    • Scott says:

      1. No reboot is usually required, however there may be times when a previous application install is still pending and a reboot may be needed to complete the install. It doesn’t force the reboot though which I imagine is more what you want to know
      2. I assume you are still talking about the automatic client upgrade? The client upgrade is not targeted at a collection, it is “targeted” to all managed devices. You do have an option to not upgrade servers though. It is an upgrade of the client, so the client retains the same SMSID and deployment history etc.
      3. Are per 2, there is no collection for the production client upgrade. You can select a collection when deploying the pre-prod client package for testing before full release which is an option you get once you upgrade to 1511 or above. The collection for pre-prod testing is one you create yourself.
      Keep in mind you don’t have to use the automatic client upgrade, you can still use a package/program/Application and deploy to your own defined collections.
      This is not a compulsory thing you have to use, and you can have a look before enabling it after you upgrade to 1511 or above.

  4. Kyle says:

    I am using MDT 2012 update 1, do I need to update to 2013 to work with SCCM 1511?

    • Scott says:

      I don’t think there is anything forcing you to update, but if you are going to the trouble of upgrading to 1511 then it is worth updating MDT as well. The process is very simple.
      You can still keep using the 2012 MDT package if you have task sequences etc referring to it. Create a new MDT package for 2013, then test and update task sequences as you go
      fyi – also plan on doing your ConfigMgr upgrade to 1602.

  5. Kyle says:

    After upgrading to 1511, the TS reboots to windows after installing configuration manager, and does not resume to install any software.
    smsts logs: “Failed to get the environment key”
    Failed with error code (0x800700EA)
    Anyone else experience anything like this?
    Thank you

    • Scott says:

      Did you update your boot images after the upgrade?

      Also, do you need to have special Disk controller drivers for the machine you are running the TS on added in WinPE?

      • Kyle says:

        I was attempting to use everything the same as 2012. I just created a new boot image and will try that. I don’t believe it requires a special disk controller.
        Thank you

  6. Wes says:

    Hello,
    I have a question.

    I already have MDT setup with a database. I am trying to install SCCM on the same server and have gotten to the point where I am to setup the SQL DB for SCCM. My question is do I need to install a separate SQL server instance for SCCM or can I use the same instance and just create a new DB?

    What is the recommended best practice?

    Thanks
    Wes

    • Scott says:

      Depends on what else your “MDT Server” is being used for and if this is a Dev or a Prod environment and what license you have purchased. Ideally you would want ConfigMgr to be on a server of its own with its own SQL.
      If you have the “ConfigMgr with SQL” license then you need to install everything on its own server and you aren’t permitted to use that SQL instance for other “non-ConfigMgr” related purposes.
      ConfigMgr needs a specific SQL collation for the SQL Instance, so if that is correct then it will use the same instance and will create it’s own DB.
      After all that, and Licensing and SQL collation aside, yes you can technically install ConfigMgr on the same SQL instance, but it’s not best practice as far as production system are concerned. For a small environment, a singe server with SQL and ConfigMgr installed on the same server is the best way to go.

  7. ersatyle says:

    thanks for this nice write up, it was very useful.

  8. Ray says:

    My DPs are gone after upgrade to 1511! any thoughts?

    • Scott says:

      That’s not really much information to work with, but I’d suggest looking at the logs on your primary and on the DPs to see what caused them to be removed and/or not reinstalled after the upgrade.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s