locked
Enroll On Behalf Of , is not working on actual device RRS feed

  • Question

  • Hi,

    I have implemented Enroll on behalf of method for enrollment, which works perfectly fine for Virtual machine.

    But when I test for actual device it is not working.

    <SyncML xmlns="SYNCML:SYNCML1.2"><SyncHdr><VerDTD>1.2</VerDTD><VerProto>DM/1.2</VerProto><SessionID>1</SessionID><MsgID>1</MsgID><Target><LocURI>9ccfa6c4-12d9-4585-a88e-6a0007e6352a</LocURI></Target><Source><LocURI>http://localhost:8000/handler.ashx</LocURI></Source></SyncHdr><SyncBody><Get><CmdID>b2306c15-bae9-4ee2-8895-76998646bfc5</CmdID><Item><Target><LocURI>./cimv2/MDM_Client</LocURI></Target></Item></Get><Get><CmdID>79a4e587-db73-4821-ab5f-49a5e90439ba</CmdID><Item><Target><LocURI>./cimv2/MDM_WNSConfiguration/MDM_WNSConfiguration.AppId=%22s-1-15-2-1286624654-688835981-2378311831-2028450411-1897650787-926617153-2462506401%22/ConfigurationStatus</LocURI></Target></Item></Get><Get><CmdID>3c8f3530-116e-4e05-9550-34b1e3579750</CmdID><Item><Target><LocURI>./cimv2/MDM_WNSChannel/MDM_WNSChannel.AppId=%22s-1-15-2-1286624654-688835981-2378311831-2028450411-1897650787-926617153-2462506401%22/Channel</LocURI></Target></Item></Get><Get><CmdID>b1729e35-b079-4ea7-96b7-b6f2de439f7c</CmdID><Item><Target><LocURI>./cimv2/MDM_WNSChannel/MDM_WNSChannel.AppId=%22s-1-15-2-1286624654-688835981-2378311831-2028450411-1897650787-926617153-2462506401%22/ChannelStatus</LocURI></Target></Item></Get><Get><CmdID>a9a89700-7a0a-4270-9514-5d75067bb8d9</CmdID><Item><Target><LocURI>./cimv2/MDM_WNSChannel/MDM_WNSChannel.AppId=%22s-1-15-2-1286624654-688835981-2378311831-2028450411-1897650787-926617153-2462506401%22/ExpirationTime</LocURI></Target></Item></Get><Final/></SyncBody></SyncML>


    When I try to get WNS Configuration Settings, I am getting 425 as result code.

    <SyncML xmlns="SYNCML:SYNCML1.2"><SyncHdr><VerDTD>1.2</VerDTD><VerProto>DM/1.2</VerProto><SessionID>1</SessionID><MsgID>2</MsgID><Target><LocURI>http://localhost:8000/handler.ashx</LocURI></Target><Source><LocURI>9ccfa6c4-12d9-4585-a88e-6a0007e6352a</LocURI></Source></SyncHdr><SyncBody><Status><CmdID>1</CmdID><MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>a7e826c1-e7fe-4e0d-b69a-fb0a29e1b688</CmdRef><Cmd>Status</Cmd><Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>21d91239-aaa9-4853-b72a-ba11c858e46a</CmdRef><Cmd>Status</Cmd><Data>200</Data></Status><Status><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>3e9f7b27-bc30-490f-a5ec-02490db14f23</CmdRef><Cmd>Status</Cmd><Data>200</Data></Status><Status><CmdID>5</CmdID><MsgRef>1</MsgRef><CmdRef>b2306c15-bae9-4ee2-8895-76998646bfc5</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>6</CmdID><MsgRef>1</MsgRef><CmdRef>b2306c15-bae9-4ee2-8895-76998646bfc5</CmdRef><Item><Source><LocURI>./cimv2/MDM_Client</LocURI></Source><Meta><Format xmlns="syncml:metinf">node</Format></Meta><Data>MDM_Client.DeviceClientID=9ccfa6c4-12d9-4585-a88e-6a0007e6352a</Data></Item></Results><Status><CmdID>7</CmdID><MsgRef>1</MsgRef><CmdRef>79a4e587-db73-4821-ab5f-49a5e90439ba</CmdRef><Cmd>Get</Cmd><Data>200</Data></Status><Results><CmdID>8</CmdID><MsgRef>1</MsgRef><CmdRef>79a4e587-db73-4821-ab5f-49a5e90439ba</CmdRef><Item><Source><LocURI>./cimv2/MDM_WNSConfiguration/MDM_WNSConfiguration.AppId=%22s-1-15-2-1286624654-688835981-2378311831-2028450411-1897650787-926617153-2462506401%22/ConfigurationStatus</LocURI></Source><Meta><Format xmlns="syncml:metinf">int</Format></Meta><Data>1</Data></Item></Results><Status><CmdID>9</CmdID><MsgRef>1</MsgRef><CmdRef>3c8f3530-116e-4e05-9550-34b1e3579750</CmdRef><Cmd>Get</Cmd><Data>425</Data></Status><Status><CmdID>10</CmdID><MsgRef>1</MsgRef><CmdRef>b1729e35-b079-4ea7-96b7-b6f2de439f7c</CmdRef><Cmd>Get</Cmd><Data>425</Data></Status><Status><CmdID>11</CmdID><MsgRef>1</MsgRef><CmdRef>a9a89700-7a0a-4270-9514-5d75067bb8d9</CmdRef><Cmd>Get</Cmd><Data>425</Data></Status><Final/></SyncBody></SyncML>

    As Prashant said in another post,

    I checked : The location of the WNS Channel is stored under the following registry hive: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\MDM

    Channel URI is there in the registry , but when I send Get command to WNS channel, I get 425 in response.

    Tuesday, February 10, 2015 6:58 AM

All replies

  • It looks like Enrollment is succeeding but you're getting result: 425 (access denied), when querying the MDM_WNSChannel properties... is that right?

    I wonder if it might have something to do with the specific user account.  Is it a standard account or admin account?


    Eric Fleck, Windows Store and Windows Phone Developer Support. If you would like to provide feedback or suggestions for future improvements to the Windows Phone SDK please go to http://wpdev.uservoice.com/ where you can post your suggestions and/or cast your votes for existing suggestions.

    Wednesday, February 11, 2015 3:43 PM
  • Hi Eric, That's right. When I query WNS channel I get 425 in response. User is a standard user. Admin user adds registry entries and enrolls standard user as EOBO. When standard user logs in, device contacts DM service. When DM service sends Get WNS channel command, device returns 425 even though I can see Channel URI exists in registry. Same scenario works without any issue in another Virtual Machine setup. On actual Surface Pro 3 device, I am facing the issue.

    P.S. : I tried on Surface 2 RT 8.1 also, I am getting 404 error there and WNSChannelLastError in registry is 0x80070490

    I would like to confirm flow for EOBO, let me know if this is correct - 

    (1) Admin user creates registry entry for EOBO standard user and turns on device management and completes enrollment. At this point WNS channel has not been received yet.

    (2) Standard user logs in to device,  Windows DM client gets WNS channel and contacts DM service 

    Is this the correct process for EOBO ?

    Wednesday, February 11, 2015 6:52 PM
  • Hi Eric,

    Sorry, this is not working in virtual machine as well.  EOBO user should always be domain user ? or it can be local standard user ? How to get UPN for local standard user?

    If local standard user is allowed, then what will be UPN for local standard user.

    Could you please clarify flow for EOBO enrollment ?

    Thank you.



    Wednesday, February 18, 2015 6:05 AM
  • Hi ,

    You can use local standard user account.It doesn't have to be domain account.

    1.Create standard user account, then login using that user account.

    2.You can use whoami /user from command prompt to the get the SID for that username(say Joe).

     3. Then UPN would be joe@test.com, it has to be in email format, but doesn't have to be working email account 

    Then login as Administrator and set the following registry:

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM]

    "MachineMDMEnrollment"=dword:00000001

    "MachineMDMEnrollmentUserUPN"="joe@test.com"

    "MachineMDMEnrollmentUserSID"="S-1-5-21-425123111-41579146940-3751321321-1002"

    More info in below blog:

    http://blogs.msdn.com/b/wsdevsol/archive/2015/01/14/windows-8-1-mdm-managing-standard-users-using-mdm.aspx

    Tuesday, March 3, 2015 12:33 AM
  • Hi Rashmi,

    Thank you very much for reply.

    I followed the same steps you mentioned, 

    I am still getting the error, for EOBO user,

    HKEY_CURRENT_USER¥Software¥Microsoft¥Windows¥CurrentVersion¥MDM

    WNSChannelLastError is 0x80070490


    Tuesday, March 3, 2015 1:16 AM
  • Hi Rashmi, Eric,

    Is there any update for this issue ?


    Friday, March 13, 2015 3:30 AM