Leon1983

Hi do you still need help with this?

Does smsts.log highlight anything significant?

I have had a bug confirmed related to Android for Work enrolled devices and Exchange Conditional access. Please see my blog post here for the workaround I have been provided at this stage https://leonashtonleatherland.blogspot.co.uk/2017/08/intune-android-for-work-exchange_9.html

0 Hi, We are experiencing multiple instances of the above event ID on both of our SCOM management servers. On the RMS the below workflows are being referenced; Microsoft.SystemCenter.CollectSignatureData Microsoft.SystemCenter.CollectPublishedEntityState Microsoft.SystemCenter.CollectEventData Microsoft.SystemCenter.CollectAlerts Microsoft.SystemCenter.CollectPerformanceData Microsoft.SystemCenter.CollectDiscoveryData On the second Management server on the below is being referenced; Microsoft.SystemCenter.CollectDiscoveryData I am led to believe this is indicating performance issues specifically with the operational Database and have followed this article to the best of my ability https://support.microsoft.com/en-us/help/2681388/how-to-troubleshoot-event-id-2115-related-performance-problems-in-operations-manager . I can also confirm that the most recent changes in our SCOM Infrastructure that may be affecting this are; 1.New Management server was added to the environment 2.SCOM Action Account had to have its password changed, which I followed the procedure as per this article http://thoughtsonopsmgr.blogspot.co.uk/2015/01/om12x-changing-passwords-om12x-service.html 3.Both the Operational and Data Warehouse Databases which almost full and only auto growing by 10MB at a time, so I have removed auto grow and sized both databases correctly, removing autogrow. I also believe that excessive configuration churn is not taking place due to the presence of event ID's 21024 being promptly followed by 21025 or 21026 in the event logs as per the following article https://support.microsoft.com/en-us/help/2603913/how-to-detect-and-troubleshoot-frequent-configuration-changes-in-operations-manager Is there anything else that I can check for on this? Regards Leon

Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_62a927af-8bc2-4ede-b504-d638e1e0c066) from type store, error = 0x80070002 Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_593ada2f-ccdd-4c31-abc2-045386837346) from type store, error = 0x80070002 My understanding is that the SUM_ guid can be matched to an actual update?

Hi Niall, I am just trying to work out how to match the SUM guid to the update itself.. any advice on this? Did you see the recent comments on the Technet post I mentioned or do you think this is an unrelated issue? Regards Leon

I cannot seem to make any headway with this, I have seen another post on Technet, with similar characteristics to this issue here https://social.technet.microsoft.com/Forums/en-US/e5a3a864-2d0c-40be-b7c7-d27b48bee17c/failed-to-get-sdm-ci-for-update-from-type-store-error-0x80070002?forum=ConfigMgrCompliance&prof=required which seem to inidicated that the SUP and WSUS components should be removed and then re added again.. I have carried out a client scan while monitoring ScanAgent.log, UpdatesDeployment.log, UpdatesHandler.log and UpdatesStore.log in the same merged view within CMTrace, and the process seems to end producing multiple errors like the below Failed to get SDM CI for update (Site_1AAA8919-CE7D-43A2-8BAF-D95647C0D2B9/SUM_e7e45f84-3523-4cd3-ab9e-685437758ebf) from type store, error = 0x80070002 Failed to GetSupersededUpdatesFromDigest for the update

I am having this same issue, with UpdatesDeployment.log reporting error 0x87d00215 - "Item not found" for all updates All of my clients are on version 5.00.8458.1005 Did you have a resolution for this in the end? I am investigating further now...

So, it would appear that this issue was related to the fact that the global admin account of which I was trying to add the subscription needed to be assigned an EMS license.

Anyone? Has anyone seen this before? I have just spoken to "Tech Support" and to be honest not getting anywhere.

I have encountered an issue where we do not appear to be able to specify SCCM as the Mobile Device Management Authority. After attempting to add the Intune subscription via the SCCM console I receive the error message "An unexpected error has occurred" I have confirmed that no MDM authority has indeed already been set, and believe that all of the network infrastructure requirements as per https://docs.microsoft.com/en-us/intune/get-started/network-infrastructure-requirements-for-microsoft-intune have be satisfied. I have can also see that the URL's attempting to be accessed are being permitted by the Firewall and passing through successfully. SCCM version is 1606 with the two hotfixes installed (I haven't installed Update Rollup 1 yet as it was released while I have been on leave for the past week or so)

Many thanks for this, exactly what we are doing and seems to work well

Please see above in bold the full command I have just realised it was incorrect. Have now used this for Surface Pro 3, 4 and Books

Many thanks for sharing your experiences on this

Anyone share their thoughts on this? I am with the mind of just keeping the base install driver package only in the system for each device and then create separate Applications for the different versions of the MSI's...