none
Fresh 1902 Install - "Bricking" server RRS feed

  • Question

  • We are in the process of setting up a new 1902 installation in anticipation of migrating from SCCM 2012. The installation runs for 1.5-2 hours without issue, and then we are presented with an error stating:

    Setup cannot compile MOF file C:\Program Files\Microsoft Configuration Manager\bin\x64\TaskSequenceProvider.mof. Do you want to continue?

    The equivalent log entry is:

    INFO: CompileMOFFile: Starting to compile MOF C:\Program Files\Microsoft Configuration Manager\bin\x64\TaskSequenceProvider.mof  $$<Configuration Manager Setup><09-19-2019 14:13:26.121+240><thread=1788 (0x6FC)>
    ERROR: CompileMOFFile: Failed to compile MOF C:\Program Files\Microsoft Configuration Manager\bin\x64\TaskSequenceProvider.mof, error -1  $$<Configuration Manager Setup><09-19-2019 14:13:26.889+240><thread=1788 (0x6FC)>

    We have tried to install three times and have the same issue each time. After the error occurs, the server becomes non-functional. Attempting to open any software/tools results in no response from the operating system, or an error stating the account does not have appropriate permissions to open the application. If we reboot the server, it does not come back online and no built-in restore actions are successful. 

    Prior to the install, the only "unsuccessful" item in the pre-requisite checker is a warning stating to verify the computer account has Full Control over the System Management container. We have added and verified this manually. The installer was able to create a container (Type = mSSMSManagementPoint) in this location, so I do not believe this to be the issue.

    We are at a bit of a loss, especially because the resulting error is catastrophic to the server.

    • Windows Server 2019 Standard
    • SQL Server 2017 Enterprise CU16 (hosted on the same server)
    Anyone have any thoughts on this? I've been pouring through as many threads as I can on SCCM installation failures and I have come up empty on a solution so far.
    • Edited by RK486 Friday, September 20, 2019 2:22 PM
    Friday, September 20, 2019 2:21 PM

All replies

  • What errors are listed within the log file. ConfigMgrSetup.log

    Garth Jones

    Blog: https://www.enhansoft.com/blog Old Blog: https://sccmug.ca/

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleashed

    Friday, September 20, 2019 3:05 PM
  • We are in the process of setting up a new 1902 installation in anticipation of migrating from SCCM 2012.

    Why are you migrating instead of just upgrading the existing instance? Migrations are far more work in all but the smallest of environments. Migrations also don't actually migrate everything and have other complications and complexities that are completely avoiding with a plain, and very simple upgrade. The only potential complexity with an upgrade is the server OS if you need to upgrade that but that can be addressed using a site backup and restore.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 20, 2019 3:19 PM
  • Wrong verbiage. It is going to be fresh. New installations of the client and pointing at the new site server.

    As for the ConfigMgrSetup.log, that is the only failure entry before it goes haywire. Just ran it a fourth time and instead chose to continue to see what would happen. Similar errors happen for smsprov.mof, netdisc.mof, bcd.mof, cmprov.mof. 

    I just tried to take the TaskSequenceProvider.mof from the \SMSSetup\BIN\X64 directory and run mofcomp manually prior to the install and receive the following message:

    C:\SC_Configmgr_SCEP_1902\SMSSETUP\BIN\X64>mofcomp _TaskSequenceProvider.mof

    Microsoft (R) MOF Compiler Version 10.0.17763.1
    Copyright (c) Microsoft Corp. 1997-2006. All rights reserved.
    Parsing MOF file: _TaskSequenceProvider.mof
    _TaskSequenceProvider.mof (15): error SYNTAX 0X8004400a: Unexpected token at file scope

    Friday, September 20, 2019 3:37 PM
  • It is going to be fresh. New installations of the client and pointing at the new site server.

    Migrations are always new installs of the client, That's one of the many added complexities. That still begs the question of why not just upgrade the existing site?

    For your issue specifically, does the system have a third-party AV product installed?

    Have you tried re-downloading the media just to rule out corruption in the media (believe it or not, this does happen and cause similar weird outcomes from time to time)?

    Are you sure that your media is 1902?

    Also, why are you using SQL Server Enterprise? That carries a huge amount of extra cost with it and is in no way required or recommended for ConfigMgr.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 20, 2019 3:48 PM
  • Existing (2012) site has been having issues for a while now and we are not convinced that an upgrade is the best thing for it. We don't want to bring the current gremlins we have been experiencing along with it.

    No third party AV. This server was brought online, Windows updates applied, went through some hardening following Microsoft guidelines, and then we started with the pre-reqs for SCCM. 

    I did re-download the media, but only because the first crash caught us so off guard that the only instance of it that we had was on the bricked server.

    Positive that it is 1902. Comes in the form of "SC_Configmgr_SCEP_1902.exe" from the Microsoft website. 

    SQL Enterprise for the improvements to memory handling. Site has 96GB of RAM and communicates with roughly 10,000 devices. Not huge, but not small. Also, we are utilizing Enterprise on our 2012 site so it was decided to maintain the same SQL level.

    Friday, September 20, 2019 4:01 PM
  • SQL Enterprise for the improvements to memory handling. Site has 96GB of RAM and communicates with roughly 10,000 devices. Not huge, but not small. Also, we are utilizing Enterprise on our 2012 site so it was decided to maintain the same SQL level.

    There's no difference or advantage here as far as ConfigMgr goes. As noted, it's a huge cost difference and Enterprise is *not* included in the System Center licensing. This is literally just throwing money away.

    went through some hardening following Microsoft guidelines,

    If I were to bet (with someone else's money) this would be the root cause here. Try, at least as a test, on a fresh OS instance without doing this.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 20, 2019 4:06 PM
  • I just reverted all of the hardening configuration changes that we had applied. Most of those changes involve forcing higher levels of encryption, authentication, disabling old ciphers, etc. Going to run through the installation again shortly. Will know the results in an 1.5 hours. I'll be happy if it works, but also a bit sad if it works. 

    I'll talk to management about SQL Enterprise being unnecessary in this scenario. Our MS partner recommended we stick with it, but if you say we truly are just throwing money away, there is some due diligence that needs to be done on our end.

    I appreciate the assistance thus far.

    Friday, September 20, 2019 5:39 PM
  • Just got back to my desk and the installation had failed in the same manner. 
    Friday, September 20, 2019 7:26 PM
  • Was it a clean OS instance; i.e., freshly installed with no security lock-downs ever applied and excluded from any group policies?

    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 20, 2019 7:33 PM
  • Make sure account used for the installation has full permissions on the site server.

    Found something related to SCCM 2007, I know its very old and the technology has changed but worth trying.

    https://microsoft.public.sms.setup.narkive.com/fy6uvYl9/compilemoffile-failed-to-compile-mof-failed-to-install-sms-provider

    Saturday, September 28, 2019 12:39 PM