We have been using SCCm 2007 for about a year and are very happy. We now want to migrate to SCCM 2012, however when we try to install our primary site it seems to break compiling TaskSequencePrivider.mof, SMSProv.mof, cmprov.mof and NetDisc.mof.  If I continue it does get to the end of the installation but I have no access to the local system. 

We are trying to install to a Server 2012 standard and prior to attempting the install we did Microsoft updates to the OS.  We are installing the SCCM into a Hyper-V system with 10GB ram. 

I'm assuming you are referencing errors in the setup.log? If so, you should list the entire relevant portion of the log otherwise it doesn't mean anything.

Do you have an anti-virus product installed and enabled on this system?

As we go through the install we get to 'Installing SMS Provider" and then we get a popup that says 'Setup cannot compile MOF file C:\Program Files\Microsoft Configuration Manager\bin\x64\TaskSequeceProvider.mof. Do you want to continue?'. If I say yes I get 32 more simular popups for smsprov.mof,cmprov.mof and netdisc.mof, if I say ok to continue on them all, then I am denied access to the file system. As for the Log file, once we get to this point I can no longer access the file system to download or view

No exotic group policies that I am aware of, I am using a mounted ISO and have downloaded a second copy and got the same results.

What about my second question (anti-virus)?

Is the server a "clean" OS build or has it been locked down/configured per some internal standards manually or using group policy?

Also note that the setup log should always persist itself in the root of the drive.

It was a fresh install from an mounted ISO. We do have group policies that are applied to lock down our servers to some point.

As for accessing the setup log, if I am logged into the VM I can not access the drive at all, just get an access denied message, and the network is in an error state as well so I can't remotely access the root of the c: drive e

It was a fresh install from an mounted ISO. We do have group policies that are applied to lock down our servers to some point.

Dazed and Confused

Thanks for all the help.  I eventually started from scratch to be sure that there were no Group Policies getting in the way and I downloaded and extracted to a local folder the install ISO for SCCM.  It now appears to be working.

Kevin

FWIW for the record of this discussion, I am now hitting this same reported issue with *.mof cannot compile warning messages.  Also after hitting the "OK" permissions on those windows to continue on with the install I have now hit the error whereby I cannot access the local file system as in I cannot launch Windows Explorer nor Services.msc ...etc. and the remaining tasks of the SCCM installer seem hung with the count timer still rolling.  The button on the installer to view the log does work oddly enough and I'm not sure under what account's context I've got access but it is visible. 

The very first 'error' entries are interesting - the second refers to WMI

#1

Info: Try Load resource from C:\Program Files\Microsoft Configuration Manager\bin\x64\00000409\WindowsStore.en.resx.  $$<Configuration Manager Setup><10-04-2013 16:26:19.477+240><thread=1768 (0x6E8)>
WARNING: Failed to find default package file C:\Program Files\Microsoft Configuration Manager\bin\x64\00000409\WindowsStore.en.resx. LastError=2  $$<Configuration Manager Setup><10-04-2013 16:26:19.478+240><thread=1768 (0x6E8)>
ERROR: Failed to convert LCID to name. Error 0x000003e5.  $$<Configuration Manager Setup><10-04-2013 16:26:19.480+240><thread=1768 (0x6E8)>

#2

ERROR: Failed to connect to WMI namespace root\cimv2 on sccm-01.domainname.local  $$<Configuration Manager Setup><10-04-2013 16:26:27.114+240><thread=1768 (0x6E8)>

Wow! There has been a lot of work to get the installation to this point and this is a major setback.

I am attempting to deploy SCCM 2012 w/SP1 standalone for the first time in this domain; it is being deployed on a Windows 2012 server using a SQL 2012 w SP1 Standard instance.  There is no AV at work interfering and no known GPO that would be interfering.  As this server has been previously been built by a Desktop Support engineer I have my doubts as to what I've inherited in light of the reported success after the original poster claimed that starting fresh worked for