Jul 23 2020 12:02 PM
Jul 23 2020 12:02 PM
I am attempting to deliver a file to my Windows 10 IoT Enterprise device using a custom Configuration profile. I am trying to follow the EnterpriseExtFileSystem CSP documentation but am having issues getting it to work. If you reference the docs, it shows the following XML file to create a file named new.txt with that simply contains "Hello World."
<Add> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/EnterpriseExtFileSystem/Persistent/new.txt</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">b64</Format> <Type xmlns="syncml:metinf">application/octet-stream</Type> </Meta> <Data>aGVsbG8gd29ybGQ=</Data> </Item> </Add>
Here is how I am trying to deploy this file via an Intune Custom Configuration Profile:
After this Configuration profile tries to apply, I get an error reading:
"-2016345697 (Syncml(415): Unsupported media type or format.)"
What is the correct way to do this? I was able to deliver files in this manner using the Airwatch MDM but can't seem to get it to work in Intune. I have also tried to paste just the Base64 encoded text in as a string data type but that didnt work either. It looks like the only option for Base64 encoded data is a certificate file. Any help would be appreciated. Thanks!
Jul 23 2020 01:56 PM
Intune doesn't allow you to use the SyncML XML to configure something. Intune does only allow OMA-URI and data value specified in integer, string, xml, ...
This is different from Airwatch which allows you to specify the SyncML xml. Intune does not allow the raw SyncML xml to be used directly. So, my assumption would be to map the datatype as best as possible, just use the base64 for the data field, but as you said you have already tried this one and it didn't work. Based on this test result, I don't see any real chance to configure it in the Intune portal. You can't specify the datatype octet-stream and base64 by yourself, like you do when using the SyncML xml in Airwatch.
Lastly, to get confirmation from MS about this assumption you could open a support request in the Intune portal.
Jul 23 2020 07:45 PM
Jul 24 2020 12:18 AM
I thought exactly the same in the beginning :-), but then I realized he talked about Windows 10 IoT and this one is based on Windows 10 Mobile afaik. Furthermore he explained he succeeded with Airwatch with the CSP and the CSP is only supported/working on Windows 10 Mobile. So a kind of confirmation that it is based on Win10 Mobile then. IME is not working on Windows 10 Mobile, so not an option imho.
Jul 24 2020 06:04 AM
Yea sorry, the device runs Windows 10 Mobile Enterprise. The device manufacturer (Honeywell) lists the OS as Windows 10 IoT Mobile Enterprise, so it can get confusing at times when trying to describe the device. What I am really trying to do is push down a device scanner profile using the OMA-URI setting ./Vendor/MSFT/EnterpriseExtFileSystem/OEMProfile as described here. It seems that this setting requires that the data be encoded in Base64, but there is no way to chose that as a data type in a custom configuration profile unless you are pushing a certificate. As mentioned before, I have tried inputting the Base64 value using a String data type but that didn't work either.
Jul 24 2020 06:34 AM
Jul 24 2020 06:54 AM
that's the paragraph from the docs article. Not sure what you are trying to say, but it describes the CSP and how content is embedded into the syncML. But still the problem is we can't define the syncML by our own, Intune constructs it for us and we only have options for the OMA-URI and the data value... that's the problem. The only viable option would be base64 which was already tested and didn't work...
Jul 24 2020 09:34 AM
I was able to get Intune to say that the configuration profile was successfully applied, but it did not seem to correctly deliver the file. What I did was I took the Base64 encoded data and saved it into a .txt file, then changed the file type to a .crt file. I then was able to import that file using the Base64(file) data type, which just pulled out the Base64 encoded data and displayed it below.
The problem is that the device scanner isn't behaving as expected, so even though it was successfully delivered, the file conversion may have corrupted the data that was sent down. At this point I am out of new ideas, I thought I was on to something here for a minute.
Jul 24 2020 09:42 AM
Interesting @_PRyan, I thought you already tried this and it still failed to deliver... That's the approach I had in mind initially. Did you convert the content back and forth just to double check that the content is valid?
Jul 24 2020 11:00 AM
I enrolled one of our development devices that allows me to browse the file system. It looks like the file is getting delivered, but the contents of the file are still encoded in Base64 instead of plain text.
Jul 24 2020 11:26 AM - edited Jul 24 2020 12:31 PMSolution
I was finally able to get it to work. I changed the .txt file containing the Base64 encoded data to a .bin file and uploaded that under the Base64(File) data type. The file delivered and was converted back to the plain text where the device could read the scanner settings. I would like to thank you for talking this through with me! Much Appreciated!