No, Registry values of type REG_MULTI_SZ will not work with this Control Module, only Registry Values of REG_SZ and REG_DWORD are supported.  This is primarily due to the limitations in the values that can be reported for Device Attributes.  Other Registry Value types would need to be converted somehow to make them value Device Attribute values.  For example, a REG_MULTI_SZ value can have embedded newlines, which would not be valid in a Device Attribute value.  Also, because they are multi-line, many REG_MULTI_SZ values are longer than the allowable value of a Device Attribute.  So, if REG_MULTI_SZ values were to be supported by this Control Module, a means would need to be provided to select which of the "multi" strings in the value should be extracted and reported as the value of the Device Attribute.

Thank you so much for this prompt and clear answer. I'm trying to find the best way to deploy about 200x MK500 with MSP using the Ethernet. We have static IP addresses for each MK500 so here's what I did : 1) I uploaded a csv file with all the IP addresses 2) I created a reg file with %1 instead of the entire IP Address (example below) HKEY_LOCAL_MACHINE\Comm\SMSC92111\Parms\TCPIP "IpAdress" = multi_sz: "192.168.0.%1" 3) I then created a registry setting and add my regfile and used the Macro 1 (%1) Replacement value to select my csv upload. 4) I created another setting using the control processManager to launch the WarmBoot.exe 5) In my Profile I have no bundle, I just have my relay server and the two additionnal settings (My registry setting for the IP Address then the process warmboot.exe) to get the MK500 connected to the network. then when the device warmboot (it is now connected) I have automatic staging to download another profile with this time my bundle where I thought it was possible to use the getresitryinfo control module to get my IP Address persistant across coldboot. Do you have any other idea to have my ethernet settings persistant across coldboot? Thank you for your help

I think I see what you are trying to do, but I am still unclear why you think you need to extract information from a REG_MULTI_SZ to do it.  From what you explained, it sounds like you are using Dynamic Staging with a Dynamic Registry Settings Object to assign a Static IP Address to the Ethernet adapter on each device.  Since the resulting Registry change won't take effect until after a reboot, a Process Manager Settings Object is used to initiate a reboot by running an EXE. So far, so good.  It sounds like you have successfully been able to Stage the device, reboot, and get onto the network via the Ethernet Adapter.  It also sounds like you were then able to have automatic Staging finish the Staging of the device over the Ethernet.  Then I start to lose you. I get that you want to have the Ethernet configuration persist across a cold boot.  I also get that won't automatically happen because the Registry Settings and Process Manager Settings were applied as Staging Settings and hence, by definition, will NOT persist.  So, in order to get the Ethernet configuration persist across a cold boot, you will need to apply some Settings Objects as part of a Bundle so they will be persistent. But since you already have defined, for each device, a value that you were able to use to assign the proper IP Address, I don't see why you would need to extract the IP Address FROM the device and send it to MSP.  Why can't you use the same information you used to construct the IP address in the first place to construct it again and send it to the device persistently, as part of a Bundle?  Now, I get that you can't do that via Automatic Staging, since Automatic Staging cannot also be Dynamic.  What I would do would be to have a Policy that sends a Bundle to all devices that applies the same Registry Settings and Process Manager Settings that were originally Staged to them.  The act of deploying those Settings as part of a Bundle will make them persistent so they will be reapplied following a cold boot.  And when they are reapplied, the device should get back on the Ethernet.