Unexpected reboot upgrading ConfigMgr Admin Console

No Gravatar

Yesterday I upgraded my ConfigMgr 2012 R2 lab to SP1 and encountered a small bit of trouble.  During the SP installation the Admin Console failed to uninstall; during installation the MSI performed an unexpected reboot.

Scenario

  • The primary site server had recently been upgraded to CU5 for ConfigMgr 2012 R2 but had several reboots since.
  • As far as I can remember the Admin Console was not running when the service pack installation began, nor any time during the installation.
  • The Admin Console failed to uninstall during the service pack installation.
  • After the service pack installation, a manual reboot was performed.
  • The Admin Console was reinstalled via command line.  The MSI return code of 1641 was generated and MSI automatically rebooted the server.

Details

Below are some details captured from the installation logs.

in C:\ConfigMgrSetup.log

INFO: AdminConsole will be deinstalled first for upgrade – "E:\Program Files\Microsoft Configuration Manager\bin\I386\ConsoleSetup.exe"/uninstall /q.

ERROR: Configuration Manager console uninstallation failed. Check log file ConfigMgrAdminUISetup.log.

WARNING: Configuration Manager console installation failed. ConfigMgrAdminUI.log has further information.

in C:\ConfigMgrAdminUISetup.log

5/14/2015 2:46:55 PM   MSI: Another application has exclusive access to the file ‘E:\Program Files\Microsoft Configuration Manager\AdminConsole\AdminUILog\CMSitePSProvider.log’.  Please shut down all other applications, then click Retry.      

5/14/2015 2:46:55 PM   MSI: Action 14:46:55: Rollback. Rolling back action:

5/14/2015 2:46:55 PM   Installation failed with error code 1603

The server was manually restarted

The Admin Console installation was initiated via command line from an elevated PowerShell ISE session.

"E:\Program Files\Microsoft Configuration Manager\Tools\ConsoleSetup\ConsoleSetup.exe" /q TargetDir="E:\Program Files\Microsoft Configuration Manager\AdminConsole" EnableSQM=0 DefaultSiteServerName=LAB-CM.lab.local

In ConfigMgrAdminUISetup.log

5/14/2015 3:28:56 PM   MSI: You must restart your system for the configuration changes made to System Center Configuration Manager Console to take effect. Click Yes to restart now or No if you plan to manually restart later.    

5/14/2015 3:28:56 PM   Installation succeeded. Windows Installer has initiated a reboot.

*Notice that the time difference in the 2 log lines in <=1 second.  Also, no visible prompt was generated asking about a reboot.

In ConfigMgrAdminUISetupVerbose.log

MSI (s) (78:04) [15:28:56:261]: Windows Installer installed the product. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0.

MSI (s) (78:04) [15:28:56:261]: Value of RebootAction property is

MSI (s) (78:04) [15:28:56:261]: Windows Installer requires a system restart. Product Name: System Center Configuration Manager Console. Product Version: 5.00.8239.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Type of System Restart: 1. Reason for Restart: 1.

MSI (s) (78:04) [15:28:56:261]: Closing MSIHANDLE (1) of type 790542 for thread 5124

MSI (s) (78:04) [15:28:56:261]: Deferring clean up of packages/files, if any exist

MSI (s) (78:04) [15:28:56:261]: MainEngineThread is returning 1641

MSI (s) (78:98) [15:28:56:261]: RESTART MANAGER: Session closed.

 

Hopefully no one else runs into this scenario.

May 15, 2015

Posted In: ConfigMgr 2012

Tags:

ConfigMgr 2012 Service Pack 2 confusion

No Gravatar

On May 14, 2015, Microsoft released a Service Pack for ConfigMgr 2012 (awesome!).  There has been some confusion as can be seen on the original announcement blog comments and the details of that confusion are laid out by Jason Sandys [MVP].  The official documentation is clear, but you have to read it carefully.  Below I’ve attempted to explain it in a slightly different way.

 

The following files were released:

  • SC2012_SP2_Configmgr_SCEP.exe (762 MB)
  • SC2012_R2_SP1_Configmgr.exe (1.1 MB)

SC2012_SP2_Configmgr_SCEP.exe is all of the following

  • The full installation source for ConfigMgr 2012 SP2
  • The upgrade for ConfigMgr 2012 (non-R2) to SP2
  • The upgrade for ConfigMgr 2012 SP1 (non-R2) to SP2
  • The upgrade for ConfigMgr 2012 R2 to SP1

SC2012_R2_SP1_Configmgr.exe is essentially a feature pack upgrading ConfigMgr 2012 SP2 (non-R2) to "R2".  This
also changes the DISPLAY VERSION of the service pack to version 1.  It does not remove any features or fixes
(to my knowledge) but only the displayed version or marketing version of the service pack (from 2 to 1).

Prior to 2015/05/14 these versions existed

  • SCCM 2012 RTM (non-R2)
  • SCCM 2012 SP1 (non-R2)
  • SCCM 2012 R2 RTM

On 2015/05/14 these versions were added (these are my version names, not Microsoft’s)

  • SCCM 2012 SP2 (non-R2)
  • SCCM 2012 R2 SP1 (this could also be called SCCM 2012 SP2 with R2)

 

The confusion is really just a marketing issue.  If the service pack were listed as version 2 for both product editions, this blog would probably never have happened.  There would probably be some footnote somewhere that mentioned that SP1 for ConfigMgr 2012 R2 was skipped, and no real confusion would have occurred.

Happy downloading.

May 15, 2015

Posted In: Uncategorized

Tags:

Domain Controller HTTP Redirect

No Gravatar

First, I’m not a networking guy so if this steps on some best practice please comment below on a better solution.

For a recent customer, a new domain (we’ll say contoso.com) was setup for both internal and external access.  The customer found that employees within the company network were not able to access the contoso.com webpage without specifying www.contoso.com.  Instead they were directed to a domain controller and thus a dead end.  Obviously we didn’t want to install IIS on each DC just to redirect the traffic.  Thankfully we found what looks to be a simple solution… port proxy at the server network interface level.  So far the testing looks perfect.

To enable the proxy (or forward)

netsh interface portproxy add v4tov4 listenport=80 connectaddress=www.contoso.com connectport=80 protocol=tcp

OR  netsh interface portproxy add v4tov4 listenport=80 connectaddress=<website IP> connectport=80 protocol=tcp

To see the forwarder(s)

netsh interface portproxy show all

To delete the forwarders

netsh interface portproxy delete v4tov4 listenport=80

 

References

https://support.microsoft.com/kb/555744

https://technet.microsoft.com/en-us/library/cc731068%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396#BKMK_1

https://supportforums.cisco.com/discussion/11994731/what-port-numbers-icmptcpudp

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

April 8, 2015

Posted In: Uncategorized

Unable to find LiteTouch.wsf

No Gravatar

Not long ago I was using MDT 2013 to develop a few images.  Deploying from the server, whether booting from PXE, CD/DVD, or a USB drive worked fine.  However, when I created a stand-alone ISO and extracted it to a bootable USB Hard Drive, the image deployment failed with the following error:

Script not found
Unable to find LiteTouch.wsf needed to continue the deployment.

The error didn’t occur if I used the same ISO attached to a Hyper-V guest.

As I investigated I noticed that both the _SMSTaskSequence and MININT folders were not on the OSDrive, but on the USB drive.  I found a few forum posts and blogs that offered DISKPART CLEAN as an option but this didn’t resolve my issue.

I eventually found some guidance from Keith Garner (MVP) that suggests that if a USB Hard Drive is larger than the target OSDrive, this error could result.  I played around with partition sizes and a few other things but it made no difference.  Only when I changed to a physically smaller USB drive was the problem resolved.

Apparently this “feature” was introduced in MDT 2012 and it still exists in MDT 2013.  Hopefully this will be fixed in MDT 2013 Update 1 (or whatever the next version will be called).

References

April 3, 2015

Posted In: Uncategorized

Windows 10 Technical Preview Build 9926 and ConfigMgr

No Gravatar

It’s a good day to not be assigned to a customer… Microsoft released Windows 10 Technical Preview Build  9926!

I took a moment to download all 4 ISO files (Professional and Enterprise, 32 and 64 bit), inventoried the ISOs to help keep track of them, and deployed one in my ConfigMgr 2012 R2 CU3 Hyper-V lab.  Here are some interesting first impressions.

 

ConfigMgr client install

CCMSetup.exe shows the computer is domain joined and X64.  Nothing unexpected there.  But notice the operating system “ ‘Microsoft Windows 10 Pro Technical Preview’ (10.0.9926). Service Pack (0.0). SuiteMask = 272. Product Type = 18.”

image

Interesting.  Let’s back up a minute and see what Windows says.

Windows version

Command Prompt shows “Microsoft Windows [Version 10.0.9926]”

About Windows (WinVer) shows “Version 10.0 (Build 9926)”

image

Let’s explore what WMI has to say about the OS

image

Manufacturer            : Microsoft Corporation
Caption                 : Microsoft Windows 10 Pro Technical Preview
Version                 : 10.0.9926
BuildNumber             : 9926
OperatingSystemSKU      : 48
OSArchitecture          : 64-bit
OSLanguage              : 1033
OSProductSuite          : 256
OSType                  : 18
ProductType             : 1
ServicePackMajorVersion : 0
ServicePackMinorVersion : 0
SuiteMask               : 272

Back to ConfigMgr

OK, CCMSetup completed successfully and everything looks good.

image

 

Now this is odd… ClientIDManagerStartup.log shows “OS Version: 6.2”.  I thought it was 10.0.9926.

image

Just to compare

  • Windows 10 Technical Preview build 9860 shows 6.2
  • Windows Server 2012 R2 shows 6.2
  • Windows 8.1 Update 2 shows 6.2
  • Windows 7 SP1 shows 6.1

At least there is some consistency, but where in the world is ConfigMgr pulling that from!

ConfigMgr Console

Let’s flip over to our ConfigMgr console.

Below is a side-by-side comparison of the 9860 build and the 9926 build from a device object property perspective.

Build 9860 shows the operating system as “Microsoft Windows NT Workstation 6.4”

Build 9926 shows the operating system as “Microsoft Windows NT Workstation 10.0”

image

And here is a side-by-side comparison of the operating system data from Hardware Inventory as shown in Resource Explorer.

Build 9860 shows a Caption of “Microsoft Windows Technical Preview” and a version of “6.4.9860”

Build 9926 shows a Caption of “Microsoft Windows 10 Pro Technical Preview” and a version of “10.0.9926”

image

Summary

With Windows 10 Technical Preview Build 9926, Microsoft has definitely changed directions with the version and left behind the 6.x series.

From a ConfigMgr perspective, the client is successfully installing, getting machine policies, running hardware and software inventory, running Software Update scans, and Compliance Setting scans.  Everything looks good… now for some OS Deployment.

January 23, 2015

Posted In: ConfigMgr 2012, Windows 10