Allan Can I use Dynamic Staging to configure each MC9090 with Static IP? I need to set each MC9090 (Windows Ce) with one unique IP Address. I create one Wlan Setting with the field "IP Address" set to Dynamic. Later, I printed the Barcode Sheets (one for each Serial Number). When I scan this barcodes, the MC9090 takes the IP corresponding to this Barcode Sheet. The only problem I have (I don´t know if this is a problem) is that the barcode works for any serial number. If I use the same barcode sheet to multiple devices, all takes the same IP Address.

Hello Pablo, I would use the on demand staging and have a staging CSV file that has the corresponding serial number of the device matched to the static IP....ie identity.serial,staging.IP (serialnumber),192.168.x.x Set your staging settings as dynamic for the IP and use the above in a staging batch to dynamically allocated the fixed IP's to each device.....the problem you will have is you need to get the settings on via a known network...so staging via ethernet dock is a good option...where you can use DHCP for the ethernet IP and a fixed IP is set per device...if you are printing barcode sheets for all fixed IP's then I think you will be forced to make sure the correct device gets the correct IP....else use a known out of the box 101 essid for wifi staging with DHCP....once the device hits the MSP sever and gets the new profile, the new profile with new ESSID and Static IP should be created and you can go from there....use on demand staging if you can Cheers Glenn

Hello Allan, I did manage to get Dynamic staging working correctly, with 2.35 OS on the MC75 and Airbeam client 7.03.23. The real issue I ended up having was that all my data was in an excel file which I exported to .csv and the unloaded into MSP, this worked fine. But it appears that Excel must have applied some funny fonts or characters to the header row..ie the staging.username row. I ended up having to delete the whole row from the .csv, manually enter it again and re-upload, everything was fine, the device uses the serial to pull down just the profile I want...nice! One other small issue - It appears that IE is the only one that works with OnDemand Staging....all others I have tried, Firefox, Chrome and Opera all display a onDemand.dll not loaded error.....is IE the only one supported?

Yes, according to the documentation, only IE is supported for On-Demand Staging.  On Page 8 of Understanding MSP 3.3, you will find the following:
----------------------------------------- MSP Console UI

A suitable Web Browser is required to operate the MSP Server functions. The User interface of MSP is called the MSP Console UI. Motorola has tested and formally supports accessing the MSP Console UI using Microsoft Internet Explorer™ versions 6 or 7, Google Chrome™, or Mozilla Firefox™ version 3.

Note: On-Demand Staging is supported only when using Microsoft Internet Explorer to access the MSP Console UI. ------------------------------------------ Beginning with MSP 3.3.1, we are switching from an Active-X Control to a Java Applet for On-Demand Staging.  At that time we will support On-Demand Staging on ALL supported Browsers.

 

Glenn; Everything you have described sounds correct. The reason why Dynamic Staging is not working like you want (automatically selecting the proper instance based on Serial Number) is likely due to one of two things. First, the RD client can only extract the Serial Number as send it to the On-Demand Staging Server running on the Workstation PC if the device HAS an electronic Serial Number.  Not all devices do, but most recent devices do.  All MC75s should unless they are eval or beta units.  However, the version of RD client must be new enough to have Dynamic Staging support in it.  If you want/need to do fresh-out-of-the-box Staging, then the version of RD client in the devcei out-of-the-box has to have the logic to send the Serial Number, which was added with the client in MSP 3.3 (version 7.02.79).  If the client is older, then it does not send the Serial Number, hence the On-Demand Staging Server sends all applicable Staging Profiles and the Device User has to pick.  If you use a newer RD client that sends the Serial Number then the On-Demand Staging Server can send just the one that matches that Serial Number and then you will get the result you want. As far as Dynamic Provisioning goes, there is no way to define Device Attributes for a device before that device exists.  So, you can not import a .CSV file to define Device Attributes for a device until after it has been discovered.  For devices that have not yet been discovered, the recommendation is to use Dynamic Staging. Allan

Hello Allan, I think you are right, Dynamic Staging is the way to go. The MC75 I have has Airbeam / MSP Client of 7.03.23...This was updated from original 4.45 version on the device. The MC75 is almost new, OEM version 1.27.0003, OS version 05.02.19600. I will try the previous version of the Airbeam Client 7.02.79 and see if this makes any difference. Also, FYI, I managed to add the Domain name to the device for GPRS using XML provisioning, creating a cab file and using MSP to deploy using staging...works well! Thanks Glenn

Glenn; There is seldom a good reason to go backwards and load an older version of the MSP Client Software.  If you have 7.03.23, then you should be able to do On-Demand Dynamic Staging based on Serial Number unless your devices is a beta one that doesn't have an ESN.  Once the device is discovered by MSP, does it report a Serial Number?  If it does, then it should be able to Stage based on it. Allan

Glenn; You cannot add new items for a Plug-In to configure without updating the code of the Plug-In to know what to do to configure those items.  So, it makes sense that adding new items to the defDoc would not make the Plug-In able to configure them.  The GPRS Plug-In is part of the MSP Agent, so updating it requires a new version of the MSP Agent.  If you need an update to that to support Domain, then you should file a GRIP explaining the need and opportunity.  And even if we do that, it won't make it work "out of the box" until some future time when that new Agent begins shipping in new OSes for a given device.  Barring that, the Agent would need to be updated before the new functionality could be used to Stage the device using that new Agent. It IS possible to change the defDoc to make items dynamic without having to change the Plug-In code on the device. So, if the need to set the Domain is not mandatory, then the Username and Password could be made dynamic just by changing the defDoc.  Of course if you change that, you are altering the delivered system and are the in realm of things that would be officially unsupported. I am a bit unclear about exactly what you are actually trying to do since you mentioned using both Dynamic Staging and Dynamic Provisioning.  The methods to do these two things are very differnet.

You could Dynamically Stage devices over Ethernet Cradle using serial number as a key, if the devices in question support serial numbers (which the MC75 does).  The process to set up Dynamic Staging is documented in the manuals, but we can provide some assistance if you can provide enough information about what exactly you are trying to do.  Essentially, you need to create a Staging Batch that defines the mapping from serial number to username and password for each device.  Then you would need one Dynamic GPRS Settings Object to receive the username and password and a Dynamic Staging Profile that deploys that Dynamic GPRS Settings Object.  When that Dynamic Staging Profile is applied in conjunction with that Staging Batch, each device should be assigned the proper username and password based on serial number. You could also do Dynamic Provisioning.  If you get the devices checking into MSP over Ethernet Cradle, then you could have a Policy that would apply a Dynamic GPRS Settings Object.  To do Dynamic Provisioning, you would need to import a CSV file to define the username and password as Device Attributes for each device and then use a Policy to deploy a Bundle containing the Dynamic GPRS Settings Object.  The Dynamic GPRS Settings Object would then be filled in with the correct username and password for each device from the defined Device Attributes for each device as it was deployed to each device. Allan

Hello Allan, I have been playing with both Dynamic Staging and Provisioning and I think I have got my head around it, but I cannot still get either process to behave the way I want 1) Dynamic Staging - So once again, I have modified the GPRS settings def doc, made the username component dynamic and reloaded as a new def doc..all is well. I have created a .CSV file with basically just two fields, one for Serial number (Staging.Serial) and the second for Username (Staging.Username), and have loaded this into Staging Batches. I have created a new GPRS settings file with the Def doc I loaded, and referenced the Staging.Username heading in the CSV file I created. Have then created a staging profile just to load this settings package. I now go into Staging Batches, and have two methods of staging, Barcode or On-Demand. I should also mention, just for testing I only have three entries in the CSV file at this stage, one real S/N and two dummy ones. If I go down the barcode path, basically, three barcodes sheets will be created, one for each S/N in the CSV. If I scan them...they work and apply settings...great! If I go down the On-Demand Path, a new Web Page pops up and the on-demand server starts. It also shows three entries here. When I run the rapid deployment client, and choose to scan connected networks, three profiles are displayed...one for each S/N....also Good!! BUT - My issue is for my deployment I will have 500 devices, and last thing I want is 500 barcode sheets or 500 profiles being displayed on the MC75 and having to get end users to muddle their way and choosing which profile is correct etc...potentially very messy What I would like, ideally, is to use on demand staging, and that the S/N of the device, would be used to display JUST the profile we wish to download...so no confusion, as on-going the customer will be restaging devices themselves. The MSP documentation is ambiguous about this and seems to imply that this is what is meant to happen, but after trying a number of things, I always get all profiles to be displayed, rather than just one. 2) Dynamic Provisioning - After reading through the doco, Implicit Dynamic Provisioning is what I want. So once again, I take the GPRS Settings file I created, place in bundle and add to a provisioning profile...but this is where I got stuck, the doco says to load attribute settings from CSV file, but it appears that this is different from the staging batches CSV file. It appears that, Dynamic Provisioning only works if the device has ALREADY been discovered by MSP AND has ALREADY has a custom device attribute set. So in the end, I created another CSV, which uses Identity.Serial,"Serial number",GPRS.Username,"Username" I uploaded via Device attribute upload and THEN the GPRS.Username is set for the discovered device, if the serial number matches. Presto, everything works. So this is fine, however, what I would really like is to pre-upload a CSV, with S/N and Username for all 500 devices, prior to MSP discoverey...same as Staging Batches. Then stage devices with basic settings, then run a provisioning package to load the correct GPRS settings based on S/N lookup of the CSV file. It appears that once the CSV file is uploaded, the settings are not retained anywhere, so it is a one shot deal to perform, only once devices are discovered and connected. From the testing I have done it appears Dynamic Provisioning is only good if all devices are already discovered and you can then, on mass, update a device attribute via upload of CSV file So for our staging process for initial devices, and for devices which have been wiped during repair process, Staging batches with On Demand is the way to go......ONLY if we can resolve issue of a single profile being displayed Any comment or suggestions on the above to improve what I am doing would be much appreciated. Thanks and Regards Glenn