none
SCCM 1902 - no permissions to download software from the software center RRS feed

  • Question

  • We are currently running Configuration Manager version 1902 (with hotfix kb4500571 installed). Recently we have found an issue with the software center. The issue is, when an application is clicked, you are greeted with a status that says "you do not have permission to install this software"

    If you click on "you do not have permissions to install this software" you receive the error below.

    I have been on the phone with Microsoft all week, and they have yet to figure out what the issue could be.

    The interesting part of this, is that only affected machines are our AirWatch enabled computers. We have reached out to AirWatch and they state the issue is on the Microsoft side. I notified our Microsoft techs of this, and they do not seem to think it is an AirWatch issue.

    We did test imaging a test computer, and the software center worked fine, as soon as it got AirWatch enabled, the Software Center would prompt the above error again.

    There are 2 things in the logs that jump out at me:

    1. in the SCClient log, it states "failed to build instance path for ScopeID" We did try to rebuild an application, but that did not solve this issue.

    2. in the CCMSDKProvider log, it states "this device is inrolled to an unexpected vendor, it will be set in co-existence mode" "Co-existence mode detected. this device is externally managed.

    I am not sure if either of those make a difference. I am just wondering if anyone has ran into this issue, or has experienced this issue since moving to SCCM 1902.


    • Edited by Ben724 Thursday, July 18, 2019 8:10 PM
    Thursday, July 18, 2019 8:08 PM

All replies

  • If you see the log line "This device is enrolled to an unexpected vendor, it will be set in co-existence mode.", it means that the machine is already managed by an MDM client. Because of that, the SCCM client will not perform management duties related to applications, updates and settings (DCM).

    Thursday, July 18, 2019 9:34 PM
  • That makes sense, but what does not make sense, is that we have had AirWatch installed for over a year. this issue just appeared when we went to SCCM version 1902.
    Saturday, July 27, 2019 7:24 PM
  • We started experiencing the same issue for our AirWatch enrolled devices after upgrading to 1902. Seeing the same co-existence message in the WUAHANDLER.log.

    Also noticed in the CCMSDKProvider.log after the co-existence message it shows "Device is in coexistence mode. Deployment/Installation of task sequences and classic software distribution packages is disabled.

     

    Wednesday, August 21, 2019 1:12 PM
  • yes, that is the same exact issue we are facing. This only afftects our AirWatch managed devices.

    We spoke to both Microsoft and AirWatch for over a month now. AirWatch went to their developers, and no changes have been made on their end.

    This is hands down a Microsoft issue. I went through the first line of techs at Microsoft, and they have no clue what is wrong.

    Now i need to open a "premier ticket" with Microsoft in order to go to tier 3. This is beyond frustrating at this point.

    If anyone has any insight into this issue, or has found the fix, please post it. 

    Wednesday, August 21, 2019 8:40 PM
  • We tested a device that was not enrolled in AirWatch but had it installed and no issues. As soon aa it was enrolled it could not install software.

    We upgraded to the latest Workspace One Intelligent Hub (AirWatch) client that was released after 1902 and we are still having the same issue.

    I am opening a ticket with Premier this morning, if this gets resolved I will post the resolution here.

    Thursday, August 22, 2019 12:11 PM
  • Looks like this is something that Microsoft introduced with the release of Update Rollup for 1902.

    Scroll down to the Additional changes section and the second bullet point is about coexistence with a Third Party MDM and a link to that article. 



    • Edited by WLesler Friday, August 23, 2019 2:32 PM Update
    Thursday, August 22, 2019 3:12 PM
  • According to Microsoft Premier the warning messages in the CCMSDKProvider.log are by design. Devices will not be able to deploy applications or software updates through Software Center with the AirWatch policy on them. 

    They are saying that if a device is windows 10 1709 or better and is either Azure AD-Joined or Hybrid domain joined then the SCCM client can coexist with a third party MDM.

    We tested this with a 1709 device that is on-premise AD joined and registered in Azure AD and it still failed.

    Thursday, August 22, 2019 6:08 PM
  • yes i tried that as well with no luck.

    They made some kind of change in 1902 that broke this. we have had Airwatch installed on all of our laptops for over 1 year. The only thing we have Airwatch set to do is wipe the devices remotely if needed. We mainly use it to manage our cell phones.

    about 80% of my computers are Windows 10 1803-1903. I have tried having one sunk to Azure with the agent and without the agent neither worked. the only thing that works is doing an enterprise wipe of Airwatch to unroll the agent, then everything is fine. Its almost like Sccm needs the ability to put itself as the 1st priority.

    the only common denominator is Sccm 1902. Airwatch and Sccm played completely fine until we went to 1902.

      

    Friday, August 23, 2019 8:35 PM
  • Did you also apply the Update rollup for 1902?
    Tuesday, August 27, 2019 3:37 PM
  • Not only did i apply the update to 1902, i also updated to 1906, and installed both patches for 1906, and the issue persists.

    Microsoft supports answer is below:

    "As per my communication this is  a by Design Behavior introduced in Newer versions ,reason as explained in last email. However if you are looking for a  Design Change Request (DCR) you may need to share the business justification  form and for the same  you need to have a premier Contract. We as a Professional Support team are a break fix  team and do not support DCR / RCA   as we do not have  expertise  in this  filed."

    This is totally unacceptable , as all SCCM users with a 3rd party MDM will be dead in the water after 1902.. Makes no sense at all....

    I went back at them explaining this, and that there has to be some kind of workaround, as this totally kills SCCM deployments and the software center.

    Tuesday, August 27, 2019 5:25 PM
  • The latest update:

    after talking to 4 different "managers" on the SCCM team, they are telling me from SCCM 1902 to present, will not work with ANY 3rd party MDM. Therefore our only options are to either revert back from 1906 to the last working version 1810 (this is not an option that i will consider) or to uninstall the AirWatch MDM....


    Tuesday, August 27, 2019 7:45 PM
  • If you see the log line "This device is enrolled to an unexpected vendor, it will be set in co-existence mode.", it means that the machine is already managed by an MDM client. Because of that, the SCCM client will not perform management duties related to applications, updates and settings (DCM).

    Based on what Kerwin said. Go to "Account Settings" on the device "Access Work and School" and remove any entry of old MDM there and the co-managed existence will be disabled
    Wednesday, August 28, 2019 3:46 AM
  • There is not any old MDM in that location, only the current one we are using (AirWatch).

    According to Microsoft, SCCM will no longer work with a 3rd party MDM after 1902... This is completely unacceptable, as there was not any notice given about this issue.

    Wednesday, August 28, 2019 1:04 PM
  • Hopefully you've raised this as an issue through the proper support channels including your TAM, account executive, support case, etc. as no one in this forum can change this.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, August 28, 2019 1:52 PM
  • The Airwatch (WSONE) SCCM Integration Client is installed?

    https://docs.vmware.com/en/VMware-AirWatch/9.3/vmware-airwatch-guides-93/GUID-AW93-Enroll_OverviewWD.html

    If you want to use AirWatch to manage Windows devices managed by SCCM, you must download the VMware AirWatch SCCM Integration Client. Use this client to enroll SCCM-managed devices into AirWatch. For more information, see the Knowledge Base article VMware AirWatch SCCM Integration Client: https://support.air-watch.com/articles/115001664948.

    Thursday, August 29, 2019 2:36 PM
  • There is not any old MDM in that location, only the current one we are using (AirWatch).

    According to Microsoft, SCCM will no longer work with a 3rd party MDM after 1902... This is completely unacceptable, as there was not any notice given about this issue.

    VMware Workspace ONE AirLift

    https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/9.7/vmware-airwatch-guides-97/GUID-AW97-Intro_Airlift.html

    it seems that VMware has a different view on it

    Thursday, August 29, 2019 3:20 PM
  • I tested with the AirWatch SCCM Integration client and it did not work. The integration client was needed with earlier versions of the Airwatch Agent but when they deployed the WorkspaceOne Intelligent Hub agent is was no longer needed.

    One of my coworkers is at VMWorld and spoke to AirWatch experts about this. He was told that VMware and Microsoft are working on a solution for this which might be rolling back the SCCM client, not the server, to a version earlier than 1902.


    • Edited by WLesler Thursday, August 29, 2019 7:06 PM
    • Proposed as answer by Geraldo Lengando Tuesday, September 3, 2019 1:23 PM
    Thursday, August 29, 2019 6:48 PM
  • We got tired of dealing with the issue. Since nobody at Microsoft or VMware had a solution for this issue, we ended up just removing AirWatch from all of our laptops. Once we did an "enterprise wipe" the software center and deployments worked like a charm again.

    We were able to get away with this, since AirWatch was only used to remote wipe our laptops, its main use is to manage our company cell phones. Our solution is, since we are moving to O365 soon, and Intune is included in our licensing, we will just use Intune to provide the remote wiping capabilities.

    I would be interested if this actually does get fixed in the future, but I would not hold my breath.

    Tuesday, September 3, 2019 8:50 PM
  • Total side question here: what's the scenario where remote wiping a laptop would even be useful? Keep in mind that connectivity to a laptop is never guaranteed or expected even and without that, remote wiping is useless.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, September 3, 2019 8:59 PM
  • We got tired of dealing with the issue. Since nobody at Microsoft or VMware had a solution for this issue, we ended up just removing AirWatch from all of our laptops. Once we did an "enterprise wipe" the software center and deployments worked like a charm again.

    That's interesting. I performed an enterprise wipe on my laptop about a week ago but it is still claiming to be co-managed and won't process anything.

    I also reinstalled the CCM client hoping it would help things along - but nothing...

    This is really annoying.


    • Edited by ifihaffto Wednesday, September 4, 2019 5:16 AM
    Wednesday, September 4, 2019 4:58 AM
  • I had that happen on my test machine. (was the only one the enterprise wipe did not solve the issue for).

    The solution was to go into the registry, and remove all of the AirWatch residue leftover. Was a pain, but fixed the issue. 

    Wednesday, September 4, 2019 3:47 PM
  • Unfortunately we are using AirWatch to manage Bitlocker on our Windows 10 laptops so unenrolling then is not an option.
    Friday, September 6, 2019 2:23 PM
  • Did anyone get any further with this?

    our organisation it certainly seems to be airwatch vs non airwatch devices.

    We are looking at Intune but that is at least 6 months away and can't have SCCM unusable for that long.

    Tuesday, October 1, 2019 2:01 AM
  • i would also be keen to see if anyone has an update here. We are experiencing this on a small scale (500 devices) currently - but will become a larger issue in the coming months.

    Surely this setting should be configurable rather than forced.

    Thursday, October 31, 2019 11:51 PM
  • Thanks for this post.

    I had a computer with this error today and no amount of troubleshooting was fixing it.

    I was ready to pull the plug and get the system re-imaged until I changed up my google search words and found this thread.

    the computer was, indeed, enrolled in Airwatch and removing the computer from AirWatch was the solution that resolved the customer's problems.

    Thanks so much for posting this.

    BTW, we found about 30 computers out of 10k+ machines that somehow managed to get enrolled in Airwatch.

    Wednesday, November 6, 2019 9:43 PM