Cumulative Update 3 for System Center Configuration Manager 2012 R2

Microsoft has released Cumulative Update 3 for System Center Configuration Manager 2012 R2.
Next to a lot of fixes it also adds new functionality on the client side to specify Management Point(s) a client may communicate with.

<quote>

Management point communications

This cumulative update introduces a new registry entry for clients. This entry will restrict which management point (MP) a client can communicate with. This can be useful in environments that have multiple MPs in different forests, and the clients can only communicate with a subset of them. Setting the registry value to only those MPs that can be reached by the client can improve overall efficiency. The new registry value is AllowedMPs, a REG_MULTI_SZ (multi-string) type that is under the following subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\CCM

Each entry is the Fully Qualified Domain Name of the management point(s) with which the client is able to communicate. This value does not affect the selection of any other site systems such as distribution points, software update points, and so on. The value only affects the primary site MP selection.

Note After this value is defined, there is no fallback or other method for clients to communicate with other MPs. This new entry is only intended for permanently located workstation and server clients and is not portable to devices such as mobile PCs or tablets.

<quote/>
 

KB2919355 installation failed

it's a kind of quick publish article :D

if you've got Windows 8.1 or Windows Server 2012 R2 in your environment you are definitely going to roll out KB291955 , or you are already doing it ;)

BUT WHAT IF IT KEEPS FAILING TO INSTALL???

there are already a lot of blogs and TechNet articles  about what to do and how to handle installation failures of KB2919355 on both client and server systems, but most of them are targeted for manual installation troubleshooting.

... hmm... one would say after reading all those network resources... that's for the users and i'm the almighty admin using SCCM (2007, 2012 etc), the most powerful enterprise management system that exists now.

... well ... the information provided below is for those out there who do use Microsoft System Center Configuration Manager 2012 (or may be still 2007) for daily operations.

when you are not using SCCM, you might still find this information useful ;)

if you encounter KB2919355 installation failure on your target systems, and you've found this article, please, before going to explore the world wide web, do the following:

1. go to the event viewer on the system where the update fails to install
2. look through the error messages in the application log
3. seek if the following ERROR message from ConfigMgr Agent exists.

If you read the error message carefully you'll see that it states that update did not finish in 600 seconds.
now, before trying anything else, let's take a look at the properties of KB2919355 in ConfigManager console.
we are interested in the settings on the "Maximum Run Time" tab.


OMG, its 10 minutes :O
I'M AFRAID IT IS TO SHORT :(
I've ran into this issue while building a complete new data center with 50TB all SSD storage with only 10 servers currently running on it, and 10 minutes were not anougth!!!
this implies that a system running in an average "normal" data center will definitely need much more time than 10 minutes to deploy KB2919355.

(possible) RESOLUTION

So, before you take deep dive into troubleshooting of installation issues, just modify the maximum run time value according to the one of the following guide lines:

• you can simply change it to something between 30 and 60 minutes
• you can manually install KB2919355 to a (server) system in your environment and use measured the installation time to estimate this value.

complete System Center 2012 cmdlet Reference Download available

Must read - Microsoft has released complete System Center 2012 cmdlet reference guide

http://www.microsoft.com/en-us/download/details.aspx?id=41196&WT.mc_id=rss_alldownloads_all

limited support for OS deployment of Windows XP and Windows Server 2003 in SCCM 2012 R2

Microsoft is trying to force users of Windows NT5.1 systems to switch to a newer OS version "by any means possible".
SCCM 2012 R2 has contains quiet some changes to make it better, faster, leaner, meaner and what so ever... but if you will try to deploy an OS on a running Windows XP or Windows Server 2003 it will fail :(
the status messages log on the site server will show you two subsequent messages:

1. The task sequence execution engine failed execution of a task sequence. The operating system reported error 2147942593: %1 is not a valid Win32 application.
2. The task sequence manager could not successfully complete execution of the task sequence. A failure exit code of 193 was returned. The operating system reported error 193: %1 is not a valid Win32 application.

and of course you can and should dig into SMSTS.log for more detailed messages on why SCCM 2012 R2 is failing to do what it was meant for ;)

to be correct it is not (only) SCCM 2012 R2 who is messing up with the things, but also Windows ADK 8.1 which doesn't support Windows XP any more :(

the first JFGI search will most likely deliver you the following thread on TechNet forums, which leads to the conclusion that these errors are caused by scanstate.exe that can't run on NT5.1 any more. The reason for this failure is that Windows ADK 8.1 ships with USMT 8.1 and it doesn't support NT5.1 any more.
This conclusion however contains only a part of actual cause!

solution 1
READ THIS BLOG POST CAREFULLY if you are migrating from Windows XP to Windows 7, Windows 8 or Windows 8.1 and want to automatically migrate user data using USMT. it also contains hint to the workaround for the remaining issue.

imagine that your task sequence does not contain any user state capture/restore steps... it will still fail with the same errors in status message log :(
the hint for the workaround is hidden in the step 4 of actual Windows 8.1 deployment procedure description in the middle of the post mention in solution 1.

"Boot the target computer by using either bootable media or via a PXE Service Point."
what the blog post doesn't explicitly says, but what actually is the current status of OSD support on  Windows XP or Windows Server 2003 is that
you can only deploy an OS to existing Windows XP or Windows Server 2003 client using PXE boot or USB boot media.

the reason lies apparently in SCCM 2012 R2 handling of  boot sector creation for WinPE on live NT5.1 system and the bootsect.exe supplied with Windows ADK 8.1.

solution 2
workaround 1 - use only USB or PXE boot to deploy OS on Windows XP or Windows Server 2003 clients.
workaround 2 - replace bootsect.exe with version supplied in Windows ADK 8.0 as suggested in this thread.

is there any hope?
there is always hope :)! there are (yet unconfirmed) messages that this issue will be addressed in cumulative update 1 for SCCM 2012 R2, until now we can use workarounds.

BTW - it would be very nice of Microsoft to add this to the known issue list of SCCM 2012 R2.

The operating system reported error 615: The password provided is too short to meet the policy of your user account. Please choose a longer password.

Recently i've upgraded a customer's site from SCCM 2012 SP1 to SCCM 2012 R2 and everything seemed to go well, even console was upgraded without any issues... until we've started deploying OS to the clients...

there are a couple of know issues described here and here so read carefully before upgrading or even installing a brand new SCCM R2 site.

the first issue - slow .wim file download - was predictable and quiet known. It is already fixed in KB2905002 and as soon as it was installed, the download speed went back to normal. According to Microsoft you should apply this cu during TS as well. Applying a cumulative update during TS is described here.

the second issue however  is far less known and there is neither hotfix nor CU from Microsoft available for it right now.

installation of an application or applications failes during Task Sequence and you ger the following error message in the log:
"The operating system reported error 615: The password provided is too short to meet the policy of your user account. Please choose a longer password."

Fortunately the guys from scug.be have already ran into this problem and were so kind to  document the solution on their blog. And i really like those guy's, because they've even shared the script to fix it site wide.

Please note: they've had this issue after upgrading from SCCM 2012 RTM to SCCM 2012 SP1. however this solution also works after upgrade to SCCM R2 screwed up your applications too.

MDOP 2013 R2 is released

MDOP 2013 R2 has been made available for download

It contains:

• App-V 5.0 SP2
• App-V 4.6 SP3
• UE-V 2.0
• MBAM 2.0 SP1
• and more ...

Both App-V 4.6 and 5.0 service packs contain only client updates, there are no server side service packs.
the latest server version for App-V 4.x is App-V 4.5 SP2
the latest server version for App-V 5.0 is App-V 5.0 SP1

unfortunately App-V 5.0 SP2 still has security descriptors enforced by default without possibility to change it. Workaround is discussed here.
as far as i know App-V dev team is still thinking what they are going to do with security descriptors in App-V 5.0

Task Sequence stops randomly

imagine:
you've installed SCCM 2012 site, configured roles, feature, client settings, set up updates management, created and tested software deployment based on the still new and still cool apllication model...
... created your build and capture task sequence, and it even did run without failures, or you were so mighty you could resolve then at no time...
and then you are ready to deploy :)...
... well thats what you are thinking, BUT SCCM 2012 seams to think differently. and your ubercool deployment task sequence, that was supposed to roll out the freshly built image just stops at some point and doesn't want to go any further :(... like the #@$%@ thing is telling you - "nope, you haven't learned enough to be that cool"

the simptoms are:
you've just captured the image using a build and capture TS.
you've added the fresh image to SCCM 2012 and want to deploy it right away.
you've even (maybe) applied some remaining updates off-line...

when this task sequence runs, it'll apply image, drivers etc, install and configure the clients and then - it'll hang up while trying to install the first application or package. the very misleading thing in this case is that if you run a script (using "run command line" TS step ;)) and specify a package, it'll work, but the very next (and first) install program or install application step will just hang up. and it'll do it like forever.
and your SMSts.log will contain entries like this:
<![LOG[Waiting for installation job to complete..]LOG]!>
<![LOG[Waiting for job status notification...]LOG]!>
<![LOG[Waiting for job status notification...]LOG]!>
...

please don't worry!
do not try to remove, rearrange or simply adjust that app or package, cause it will not help!

this discussion on the Technet contains the solution!
so don't be a hero, just execute the script below before capturing the image :D

strComputer = "."
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\ccm")
Set colSWbemObjectSet = objSWbemServices.InstancesOf("SMS_MaintenanceTaskRequests")
For Each objSWbemObject In colSWbemObjectSet
strInstance = "SMS_MaintenanceTaskRequests.TaskID='"&objSWbemObject.TaskID&"'"
objSWbemServices.delete strInstance
Next

 thats how the corresponding TS step could look like...