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:
USE OperationsManager GO 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: 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:
Use the following query to find a specific applictaion and its deployment data, change the softwareName and softwarePublisher fields to suit.
SELECT tblAssets.AssetName, tblAssets.DOMAIN, tblAssets.AssetUnique, tblSoftwareUni.softwareName, tblSoftware.softwareVersion, tblSoftware.Installdate 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.
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: http://support.microsoft.com/kb/2736596
So USMT should protect and migrate these files... it just doesn't.