Author: Chris Bradford

Issues with the Network Access Account following an SCCM 2012 R2 upgrade are not uncommon:

• http://social.technet.microsoft.com/Forums/en-US/7926a4ff-6ace-434b-bbba-7ddd00f3fda2/2012-r2-osd-refresh-winpe-network-access-account-issue?forum=configmanagerosd
• http://anoopcnair.com/2013/10/29/sccm-configmgr-2012-r2-known-issues/

Despite creating a new account, deleting the old account and recreating boot images we were still running into issues on some refresh scenarios with Task Sequences failing with a 80070002 error code – bare-metal deployments of new machines were fine, using the same boot images.

It turns out that the clients targeted by the refresh Task Sequence we’re still running the legacy, non-R2, SCCM client. After upgrading the client to the R2 version all Task Sequences ran without issue.

A revised version of a script I found here:
http://ccmexec.com/2012/02/installing-multiple-windows-7-hotfixes-msu-with-sccm/

Use this script in an SCCM package that contains MSU fuiles to mass install updates. You can include as many MSU files as you like.

Recently completed an R2 upgrade of a Primary Site with multiple Secondary Sites, as expected this was ‘interesting.’ I’ve captured our experiences below – hopefully this will be useful for someone else about to go through a similar excerise.

We’re currently testing a Windows 2012 R2 DirectAccess deployment, part of this is includes a swathe of application testing. During this testing we found that SCCM clients were unable to download content from any DPs, meaning Software Deployment was failing when connected via DirectAccess. The solution is not suprising – you need to modify the SCCM Boundaries and ensure you have defined a boundary for your IPv6 Prefix, assigned to your DirectAccess clients.

To find the prefix, view the properties of a DirectAccess-enabled device in SCCM – you’ll see the detected IPv6 prefixes within the captured properties. Simply add the correct prefix to your SCCM boundary configuration.

This has been a personal bugbear of mine for a while – if DPI settings on a client device are set to 125% or even 150% the SCCM Application Catalog is terrible, requiring users to scroll in virtually every direction to use the website.

I came across the following MS connect post today that offers a temporary workaround.

Modify the Main.css file located under: <SCCM install directory>\SMS_CCM\CMApplicationCatalog\Content\Main.css, change the #ASPcontainer element to look as follows:

#ASPcontainer
{
position: fixed;
height: 99.5%;
width: 100%;
}

This will not survive re-installation of the AppCat role, nor will it survivce AppCat upgrades. Change requires no restart/iisreset – effective immediately.

We’re currently testing a ML Windows 8.1 build – 30+ languages, so languages are injected on demand, based upon network location. One thing we ran into was that the Modrn App tiles were still in the base OS language (en-US).

This appears to be a known bug as outlined here: http://support.microsoft.com/kb/2928948/en-us

The solution? Simply add a Run Command Line task to your Task Sequence after “Setup Windows and Configuration Manager” stage to execute the following command:

{code lang:text showtitle:false lines:false hidden:false}Schtasks.exe /change /disable /tn “\Microsoft\Windows\AppxDeploymentClient\Pre-staged app cleanup”{/code}