Cam across this error recently when trying to push the agent using discovery qizard:

One or more computers you are trying to manage are already in the process of being managed

From SCOM OPS SQL Database use the following TSQL to resolve this issue:

View source
USE OperationsManager
SELECT AgentPendingActionId, AgentName
FROM AgentPendingAction
WHERE AgentName LIKE 'ServerName%'
--As long as the above returns something useful, then run
DECLARE @ActionId uniqueidentifier
SET @ActionId =
 SELECT AgentPendingActionId
 FROM AgentPendingAction
 WHERE AgentName LIKE 'ServerName%'
EXEC p_AgentPendingActionDeleteByIdList @AgentPendingActionIdList = @ActionId

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:

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:

View source
Schtasks.exe /change /disable /tn "\Microsoft\Windows\AppxDeploymentClient\Pre-staged app cleanup"

Use the following query to find a specific applictaion and its deployment data, change the softwareName and softwarePublisher fields to suit.

View source
SELECT tblAssets.AssetName, 
FROM tblAssets 
    INNER JOIN tblSoftware ON tblAssets.AssetID = tblSoftware.AssetID
    INNER JOIN tblSoftwareUni ON tblSoftware.softID = tblSoftwareUni.SoftID
WHERE tblSoftwareuni.softwareName LIKE '%Helper Object%' AND tblSoftwareUni.SoftwarePublisher LIKE '%microsoft%'
ORDER BY tblAssets.DOMAIN, tblAssets.AssetUnique, tblSoftwareuni.softwareName

Use the following WQL queries to identify devices by architecture - this makes rolling out SCCM client updates a little easier.

The WQL below can be used to create an X64/64-bit device collection. Simply modify X64-based PC to "X86-based PC" to create a collection for X86/32-bit devices.

View source
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.SystemType = "X64-based PC"

I was under the impression that USMT will save/copy any unsynchronised offline files, whilst ignoring files that are safely synchronised elsewhere - until recently.

On performing an in-place refresh from Windows Vista x86 to Windows 7 x86 SP1 we had a single user who's un-sync'd offline files were not saved/copied by USMT. Unfortunately there was little we could do after the event, other than try and work out why, without the scanstate.log files.

I then came across the following Microsoft KB:

So USMT should protect and migrate these files... it just doesn't.

Read more: ConfigMgr : USMT 5 and Offline Files

Page 1 of 20