Posted on October 14th, 2014 No comments
I’ve encountered quite an interesting issue when deploying a custom iOS (IPA) app using System Center Configuration Manager and Intune. The problem is that the deployment status for the app never reports as “Success” and is hung at “In progress”. As it turns out there is a mismatch in the version info that exist within the IPA file and the plist file that is included when deploying the IPA.
The CFBundleVersion listed within the IPA in the file info.plist
must match the bundle-version found in the plist file that is used when creating the app deployment in Configuration Manager.
If these values do not match the status will never be reported as successful in the ConfigMgr console. After the September 2014 maintenance window for Intune I also suspect that this version mismatch is causing the app to be re-deployed over and over again, however this has yet to be confirmed.
Note: You can easily check the content of info.plist within the IPA by renaming the IPA to ZIP and extract its contents. Use a plist viewer of your choice (there are several free for trial) to check the CFBundleVersion.
Posted on August 18th, 2014 No comments
When adding the Monitoring and Administration Feature of MBAM 2.5 and checking the System Center Configuration Manager Integraton features in the setup wizard you typically enter the URL to the Reporting Server, for instance http://configmgrsrv/ReportServer. If you get the error
The SQL Reporting Services URL that point to the MBAM reports is not valid
it actually means that you before installing the Monitoring and Administration features must install the MBAM Reports feature. That is even though you are integrating MBAM into System Center Configuration Manager. Why is that? Because when integrating MBAM with ConfigMgr, the only reports that are managed in ConfigMgr are the compliance reports.
Posted on July 16th, 2014 No comments
If you are using System Center Configuration Manager 2012 R2 and Windows Intune to deploy email profiles to your iOS devices you should be aware of the fact that the email policy will vanish from your users’ iOS devices and then user then need to log in to the company portal for the email profile to get deployed once again to the iOS device. This is true in the following scenarios:
- You make a change to the email policy, for instance changing the name of the email policy in the ConfigMgr console.
- You install Cumulative Update 2 for System Center Configuration Manager 2012 R2.
No status on a fix for this bug at the moment.
Posted on July 7th, 2014 No comments
A common setup when using System Center Configuration Manager to deploy is to have an OSD collection which has a required deployment. Moving clients to that Collection will let them be reinstalled or installed. After deployment is done you typically want the machine removed from that collection. There are a few ways of doing that but my favorite is using an Orchestrator runbook.
Orchestrator Runbook Configuration
Note: In this guide I assume that you have installed System Center Orchestrator 2012 SP1 or 2012 R2 in your environment.
1. First you need to download and install the Orchestrator Integration for Configuration Manager which will add the items we are using to remove the machines from a Collection in Orchestrator Runbook Designer.
2. Start Orchestrator Runbook Designer and setup the connection to the ConfigMgr primary site server by going to Options > SC 2012 Configuration Manager.
3. Add a connection to your SCCM server and make sure to test the connection using the Test connection button before proceeding.
4. Now Create a new Runbook and go to Activities > Runbook control and drag “Initialize data” to the Orchestration pane. Do the same by choosing SC12012 Configuration Manager under Activities, and then drag “Delete Collection Rule” out on the Orchestration pane.
5. Hover over the Initialize data icon and then drag the arrow to the Delete Collection Rule. It should look like the below image.
6. Right click Initialize Data and choose Properties. Add two details and name them CollectionID and ClientName.
7. Right click Delete Collection Rule and choose Properties. Start by choosing the connection you created in step 3. Note: Do not type in the text as below, instead right click the area right to Collection and choose Subscribe > Published Data. Choose CollectionID and click OK. Repeat for Membership Rule. Choose Finish when done.
If you type in the text manually you will get this error when executing the runbook: The SMS Provider reported an error. Details: Generic failure
8. Before proceeding I strongly recommend that you execute the runbook in test mode, supplying a client name and collection ID of a machine located in the collection you want the client removed from.
Note: Do not forget to check in the runbook after testing and when you are done, or it will fail to execute during operating system deployment.
Task Sequence Configuration
Now that the runbook is running successfully you can use it in your Task Sequence. Note: This requires that you have integrated Microsoft Deployment Toolkit with Configuration Manager and that you are using an MDT Task Sequence.
Modify a task sequence and create a New group. The recommended section to run the Runbook is in the State Restore phase of the Task Sequence. To be on the safe side first run a “Gather”, then you must add “Use Toolkit Package” and last but not least execute the actual runbook by adding the “Execute Runbook” step.
Also note that runbooks are run with the SCCM network access account so you must add that account to the Orchestrator user group that you have assigned, check the permissions and which group name to add to the relevant Orchestrator group in Runbook Designer by right clicking the name of the runbook tab and then choose Permissions.
If you do not you will get this error in the ZTIExecuteRunbook.log (where all events related to the runbooks are stored):
Unexpected response from web service. 405 Method Not Allowed
< ?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
< error xmlns=”http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“>
<message xml:lang=”sv-SE”>The requested operation requires Publish permissions on the
< /error> ZTIExecuteRunbook 2014-07-03 10:01:56 0 (0×0000)
Happy orchestration and deploying!
Posted on July 4th, 2014 No comments
After extensive troubleshooting, hours after hours, I have finally located a certainly interesting problem with the install routine of modern apps, including the immersive control panel in Windows 8.1 (with Update).
Whenever a user logs into a domain joined Windows 8.1 machine all modern apps included in the image have “x” / crosses on them and they cannot be started. Also the immersive control panel an all its settings are unavailable. A few of the error messages and codes:
Trying to start a modern app:
This app can’t open. There’s a problem with <app name>. Contact your system administrator about repairing or reinstalling it
This app does not support the contract specified or is not installed.
and in Swedish:
Den här appen stöder inte det angivna avtalet eller så har det inte installerats.
Trying to install an app using Add-AppxPackage PowerShell cmdlet:
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF6, Package could not be registered. error 0x8007064A: Cannot register the request because the following error was encountered while initializing the windows.repositoryExtension extension: The configuration data for this product is corrupt. Contact your support personnel.
After going through a bunch of GPOs and hundreds of settings and excluding the most likely settings I finally reached out to what turned out to be the cause. Simply the use of “restricted groups” in group policies to add NT AUTHORITY\SYSTEM to the local Administrators group on the Windows 8.1 machines is what is the cause. The problem can easily be reproduced by adding SYSTEM to the Administrators group on domain or non-domain joined machines.
BE AWARE: SYSTEM has more privileges on a Windows box than an Administrator. Adding SYSTEM to the local administrators group effectively lowers the privileges of the SYSTEM account which apart from apparently causing modern apps to fail have a bunch of other unpredicted results on a Windows machine.
The solution is to remove SYSTEM from the local Administrators group from being applied via restricted groups. Adding the group SYSTEM to the local Administrators group is not necessary as SYSTEM is a member of the Administrators group per default, although it is not visible in the GUI (Computer Management).
Posted on June 28th, 2014 No comments
When deploying Windows 8.1 Machines using System Center Configuration Manager 2012 R2, me and as good as everyone ever done a Windows 8.1 deployment using CM2012R2, has seen the issue. The issue is that the first time a user log in to the deployed machine, it gives an error:
The Group Policy Client service failed the sign-in.
The universal unique identifier (UUID) type is not supported.
The problem has been seen from time to time but at last there is a solution to this elusive problem. The solution or workaround actually, is provided in KB2976660: First logon fails with “The universal unique identifier (UUID) type is not supported”.
Posted on April 13th, 2014 No comments
One very common problem that I encounter every now and then with customers and when doing Windows training is the fact that remote controlling computers causes a freeze in the remote session when UAC kicks in. By default, UAC prompts for elevation on something called the secure desktop, and that effectively blocks any remote input.
This problem can be fixed by changing the necessary UAC settings. Just as a note; Never ever turn off UAC!
Configure UAC to allow for remote support by setting the following GPO settings under Computer Configuration / Policies / Administrative Templates / Windows settings / Security settings / Local policies / Security Options node:
User Account Control: Switch to the secure desktop when prompting for elevation policy = Disabled
User Account Control: Allow UIAccess application to prompt for elevation without using the secure desktop policy = Enabled
Posted on March 27th, 2014 No comments
Encountered an interesting issue doing Windows 8.1 Deployment using ConfigMgr 2012 R2. A specific model was constantly failing at the very last step in the task sequence. The smsts.log revealed a few errors with the codes 80070002 and 80072ee2, failing at random files every time from the MDT Toolkit Package.
A few examples:
DownloadFiles() failed. 80072ee2.
DownloadContentAndVerifyHash() failed. 80070002.
It seems Microsoft is aware of the issue and the current workaround is to set the following variables first in the task sequence to address the problem until it hopefully will be fixed in a coming hotfix.
SMSTSDownloadRetryCount = 5
SMSTSDownloadRetryDelay = 15
After settings these variables the deployment finish as expected.
Posted on March 18th, 2014 1 comment
There is something fishy going on when deploying email profiles to iOS devices using Windows Intune and ConfigMgr 2012 R2. When you have deployed an email profile to an iOS (7.1) device you cannot choose to send pictures from that email account, as the account is then missing from the drop down menu when choosing “From”.
If you go into the Mail app in iOS and then write a new mail then you can choose the deployed email account, the problem is just related to sharing pictures (possibly also other stuff) via the “Share button” > Mail feature in iOS.
Note: If you go to Settings > Mail, Contacts, Calendars you cannot see the email account listed in “Default account”.
UPDATE: Turns out that this is indeed not a bug but a feature. You must activate “Allow email to be sent from third-party applications” in the email policy.
Posted on March 15th, 2014 No comments
I encountered a stuck deployment at the “Getting ready” stage when deploying Windows 8.1 at a customer site the other day. None of the logs produced by the task sequence gave any indications on the problem at that stage so to find the real problem I had to turn to the Windows setup log setupact.log which is found in C:\Windows\Panther\UnattendGC.
In clear text it stated a few lines of this code. It kept on retrying to join the domain every ten seconds.
2014-03-14 10:48:23, Warning [DJOIN.EXE] Unattended Join: DsGetDcName failed: 0x54b, last error is 0x0, will retry in 10 seconds...
That particular problem was caused by the fact that the domain name to be joined was not entered as a FQDN in the task sequence. Note there are other causes of a failed domain join but remember that if your Windows 8.1 installation hang at “Getting ready”, examine the setupact.log and find the root cause and fix it.
Interesting to say is that this behavior seems to be different in Windows 8.1 than in previous Windows versions (at least Windows 7), where a failed domain join would be skipped and the deployment would continue leaving the machine in a workgroup mode.