Issue using deviceidmanager for an Azure WebJob command line RRS feed

  • Question

  • I have build a command line app which connects to CRM and outputs some data to an FTP location.  It is working well.

    I thought I would deploy it to Azure as a WebJob so that it could be scheduled.

    I received errors from the deviceidmanager relating to the file location of the deviceid details.  I found an article and made the changes below which seemed to fix the issue.

    private static class LiveIdConstants
                public const string RegistrationEndpointUriFormat = @"https://{0}/ppsecure/DeviceAddCredential.srf";
                public static readonly string FileNameFormat = Path.Combine(
                public const string ValidDeviceNameCharacters = "0123456789abcdefghijklmnopqrstuvqxyz";
                //Consists of the list of characters specified in the documentation
                public const string ValidDevicePasswordCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^*()-_=+;,./?`~";
    private string Encrypt(string value)
                if (string.IsNullOrEmpty(value))
                    return value;
                byte[] encryptedBytes = ProtectedData.Protect(Encoding.UTF8.GetBytes(value), null, DataProtectionScope.LocalMachine);
                return Convert.ToBase64String(encryptedBytes);
            private string Decrypt(string value)
                if (string.IsNullOrEmpty(value))
                    return value;
                byte[] decryptedBytes = ProtectedData.Unprotect(Convert.FromBase64String(value), null, DataProtectionScope.LocalMachine);
                if (null == decryptedBytes || 0 == decryptedBytes.Length)
                    return null;
                return Encoding.UTF8.GetString(decryptedBytes, 0, decryptedBytes.Length);

    Note the use of LocalMachine the WebRoot Path.

    Things were fine for 24 hours and then I started getting the following error:

    System.InvalidOperationException: Unable to Deserialize XML (Operation = Loading Device Credentials from Disk):

    System.InvalidOperationException: There is an error in XML document (5, 5). ---> System.Security.Cryptography.CryptographicException: Key not valid for use in specified state.

    at System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope)

    [09/02/2016 14:38:00 > 86fffa: INFO]    at Microsoft.Crm.Services.Utility.DeviceUserName.Decrypt(String value) in C:\Projects-Online\***\LetterBatchTool\Helpers\deviceidmanager.cs:line 981

    I am unsure why the code worked and then broke without intervention.  It had been running every hour for testing purposes. 

    Could the file have become corrupt?  Do I need the file? Is there maybe a way to bypass it or store the data another way?  Perhaps a simple amendment to make it use hardcoded values or create the data fresh every time?

    Friday, September 2, 2016 3:03 PM

All replies

  • I renamed the LiveDeviceID.xml file on the web server and the app succeeded creating a new file in the process.

    I obviously don't want this to fail intermittently.  How should I approach making the deviceidmanager "self healing"?

    Is there a method in there that I can call when the error happens that will create a new file or a flag I can set?  Why would the xml file corrupt?

    Friday, September 2, 2016 3:16 PM
  • Examined the old and new files and they look structurally fine.  They do have different encrypted strings so presumably the new file generated new codes.

    Apologies for my ignorance of the deviceid.  Is this data passed to CRM as a form of contract?  Does it do harm to generate more then 1 of these files?

    Friday, September 2, 2016 3:32 PM
  • Full weekend of executing every hour and it has not failed again.  Maybe the issue is gone.

    At this stage I have removed the corrupt XML file and redeployed the command line app.  Maybe all my deployments during development caused the corruption.

    Of course I am saying corruption but the file looked fine to the eye it was simply that the application wasn't loading it correctly.

    I will continue to monitor over the next few days.

    Monday, September 5, 2016 10:00 AM