locked
MDM - Win Phone 8.1 sending PFN to device RRS feed

  • Question

  • I'm attempting to send the VS generated PFN to a mobile device during a check-in, but I keep getting a 418 error which is described as 'already exists'. So, I attempt a replace and instead get a 500 error.

    Below is the SyncML for the Add.

    <Add>
    <CmdID>fa346283-e5ca-4ff1-b860-9b7cc8dc365e:4</CmdID>
    <Item>
    <Target>
    <LocURI>./Vendor/MSFT/DMClient/Provider/ourproviderID/Push/PFN</LocURI>
    </Target>
    <Meta>
    <Format xmlns="syncml:metinf">chr</Format>
    </Meta>
    <Data>5XXX7cXXXXXXXX.XXXXwnstest_XXXXXXxwdXXXX</Data>
    </Item>
    </Add>

    Any advice would be much appreciated!

    Cheers.

    Daniel

    Monday, September 22, 2014 1:47 PM

Answers

  • I think I've found the cause of the 500 errors on replace: the device is attempting to use the cellular data connection to do some sort of registration upon receiving the new PFN.  My test device does not have a valid data plan on it.

    When I put the device in airplane mode, with wifi on, it succeeds.

    • Marked as answer by DannyConroy Monday, October 6, 2014 8:31 PM
    Monday, October 6, 2014 7:19 PM

All replies

  • Can you please follow the steps outlined in the below blog and let us know if you still see the issue?

    http://blogs.msdn.com/b/wsdevsol/archive/2014/08/21/windows-phone-8-1-mdm-push-functionality.aspx

    Monday, September 22, 2014 7:10 PM
  • That was actually my starting point - as the last comment on that page from last week was mine. I thought maybe I was missing another step, perhaps during enrollment. 
    Monday, September 22, 2014 8:10 PM
  • We had seen similar issues reported in forums before. Unfortunately, we don't know the root cause. However, in some cases, when Add fails with 418, replace worked. In other cases, they did factory reset to recover.

    Have you tried querying the channel uri? Does it fail?

    Tuesday, September 23, 2014 9:58 PM
  • I am also seeing the same issue - Add fails with code 418 and Replace fails with 500.  Querying the Channel URI returns 404. 

    A factory reset of the device did not resolve the issue.  Is there anything else we can try to diagnose this?

     

    <Get>
      <CmdID>2</CmdID>
      <Item>
        <Target>
          <LocURI>./Vendor/MSFT/DMClient/Provider/ourID/Push/ChannelURI</LocURI>
        </Target>
      </Item>
    </Get>
    ...
    <Replace>
      <CmdID>3</CmdID>
      <Item>
        <Target>
          <LocURI>./Vendor/MSFT/DMClient/Provider/ourID/Push/PFN</LocURI>
        </Target>
        <Meta>
          <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>ourPFNtoken</Data>
      </Item>
    </Replace>
    
    ...
    <Status>
      <CmdID>7</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>2</CmdRef>
      <Cmd>Get</Cmd>
      <TargetRef>./Vendor/MSFT/DMClient/Provider/ourID/Push/ChannelURI</TargetRef>
      <Data>404</Data>
    </Status>
    
    ...
    <Status>
      <CmdID>14</CmdID>
      <MsgRef>1</MsgRef>
      <CmdRef>3</CmdRef>
      <Cmd>Replace</Cmd>
      <Data>500</Data>
    </Status>

    Wednesday, September 24, 2014 9:21 PM
  • Querying both the channel uri && the status both return a 404. 

    The strange thing is that with the same device, just last week, it was actually able to receive the PUSH PFN and return back a valid channel uri. However, with testing, we un-enrolled the device and now it's doing what it did in my initial post. 

    It's strange and peculiar knowing it sometimes works and sometimes doesn't. Still haven't figured out the root cause. 

    Monday, September 29, 2014 7:19 PM
  • I've discovered twice now that when I leave a device enrolled and periodically checking in every 15 min, after a while the replace command for the PFN will suddenly start working.  The first time it happened on a Monday after leaving the device (enrolled Friday evening) checking in over the weekend, the second it happened about 6 hours after the device was enrolled.

    One pattern I noticed is that with all of the 500 responses, there was a consistent 30 second delay between the server sending the replace command and the client returning the response message.  It is always exactly 30 seconds - until it succeeds, then it is very quick.  This is the only time I've seen such delays from the client.

    Tuesday, September 30, 2014 7:36 AM
  • After running Dev power tools on the device while sending the PUSH PFN command, I see funky data.

    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete
    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete
    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    [MDM DMScheduleAdmin Start] Commandline: C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete 

    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete
    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete
    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /RenewalSchedule /Delete
    C:\Programs\EnrollmentClient\DMScheduleAdmin.exe /Provider "com.ourrpovID.emmc" /Push /Delete

    I can't say I understand any of that. But, its clearly not adding a /Push. 

    Thursday, October 2, 2014 9:03 PM
  • I think I've found the cause of the 500 errors on replace: the device is attempting to use the cellular data connection to do some sort of registration upon receiving the new PFN.  My test device does not have a valid data plan on it.

    When I put the device in airplane mode, with wifi on, it succeeds.

    • Marked as answer by DannyConroy Monday, October 6, 2014 8:31 PM
    Monday, October 6, 2014 7:19 PM