If the general issue is network access, why not using this 2577 folder + autorun.exe cute feature on SD? Of course, only on devices with USB Host mode available. Anyway, on the other hand, having custom Golden images is a good idea... as long as Repair Centres may push them to repaired units (for given customers). This would pretty much help, since neither the customer or the partner whatsoever should have to stage the returned terminals. Also (perhaps just a silly thought) does WM support BOOTP? That could be a way too.

Thanks for all of the replies sounds like we have a very interesting topic. Has anyone tried any off the shelf WinMo cloning software like: Sprite-Clone: http://www.spritesoftware.com/products/sprite-clone

One of my customers identified a significant problem with Sprite-Clone - unique terminal attributes. When a clone is created it includes terminal specific, unique attributes which in many cases must be modified to be able to use the clone on a different terminal. This is usually done manually unless a separate application is included to programmatically update the clone image.

The problem with any new deployment tool would be to fit somewhere in between the existing StartUp Control and MSP. The former copes quite well with standard install and launches. It only suffers in not being able to 'type' in config dialogs for difficult installs. That could well be a good extension to it and would make it more comprehensive. MSP does very well on simple installs and complex ones though it does require network access. It can even get to the 'put a bar code on the notice board somewhere' and get a device configured for use. Some 5 years ago I created a complete clean and wipe, install and launch package for Tescos for WM5.0 on the MC70. This allowed just the scenario you give and it was given to the customer as a 'example C++ code' of how this could all be achieved and thus adopted by them for their own maintenance going forward. This, then, provided a fully supported solution, script driven for flexability, that the customer was happy with but with little to no Motorola risk downstream for any incompatabilites that arise due to OS changes in the way things work in the future.

Rob, there are a lot of good reasons why to use a gold image Definition of Golden Image : the OS & the Drivers & the Hotfixes & the Settings & the Customer Application which makes the full customers solution. In bitter reality most partners/developpers are only looking after their Customer Application - then this go with a test unit to their customer - then an issue with the phone - a RIL needs to be updated - then an other hotfix here and an other hotfix there and - hey - here is an other BTStack or Fusion-Build and an other ABUP and an other regkey - but at some point in time - hopefully - the customer is happy and is starting the rollout - not having a golden image is already hurting at staging. But that was maybe done somehow with a lot of effort and times goes by - in the meantime they ordered some more devices and maybe sent some devices in for repair. After some while they have maybe 10 or more different configured devices in the field and nobody knows why something is not working here while it is working there. I have seen this above story with so lot of installations and I am really promoting (not to say praying) to partners/developpers to not only look to their application but to the whole solution which means to use the golden-image-approach. Having a management-system like MSP is a littlebit easing the effort on this - but this depends on how much of different "add-ons" are required to get a working solution. And a customer - at least in Central Europe - want to stage a device ONCE with ONE barcode sheet not to stage a device 10 times with 10 different barcode sheets. We are serving ENTERPRISE business ! Not promoting golden image would be following the CONSUMER business approach - everybody can look into his C:\Windows folder and will easily explain the meaning of the $...KB...$-dirs/files, isn´t it ? Maybe it is also a lack of our tools - or better the quality or the lack of documentation of it - why not more people are using it or are willing to use it. I would strongly recommend to AT LEAST continue for all MCD-products the ability to create customized OS builds - or make it even better ! This is definitely a strong competitive advantage in the ENTERPRISE business.

You have identified something that I see as a deficiency in our product and support offering – a way of completing what I call 'staging' our devices. Even for our customers that have MSP but for whatever reason MSP cannot connect to their terminal and they need an automated local process to quickly reimage the terminal to a known state.

 

I felt so strongly about this need that I submitted my proposed solution to the 2010 EMS Virtual Innovation Symposium and my idea has been accepted into the VIS Showcase. My solution allows customers to rollout and manage a ‘Gold Image’ that can be modified and/or invoked remotely or locally to restore a terminal to a known state. I am calling my solution eMStage (code named ‘Generic Staging’). eMStage is highly configurable and easily managed via remote management tools such as MSP, SOTI, CloudSync, Wavelink, etc.

 

With the help of the US West TA team eMStage has evolved and is currently used by large and small customers. eMStage was a significant reason why my account team won the $11M Con-way contract and IBM uses eMStage in their provisioning facility to prepare Con-way’s new terminals. One of our partners that support the Nike account plans to sell eMStage to Nike so that Nike can eliminate a significant number of No Problem Found service calls, software lockups, and other issues that can in many cases be resolved by simply reimaging their MC70 terminals to a known state. Nike’s store managers will simply have to press four buttons on their MC7090 terminals and eMStage will wipe the device clean, validate the OS, reload registry configuration and cab files, and then warm boot into the Wavelink Enabler to scan-to-config the terminal according to each store’s specific configuration. All of this can be done with no intervention – not even calibrating the screen.

 

eMStage has one shortcoming that could prevent it from currently being fully supported by Motorola – it’s built on SymScript and a caveat EULA is included to remind the customer that the free eMStage application belongs to them and it is NOT SUPPORTED by Motorola.

 

I’ve done significant work on defining the underlying logic flow of eMStage’s engine and would love to talk with others on how we can put this into a fully supported product – much like other Motorola MCD tools (Startup Control, SCM, etc.). And I feel that the underlying engine that drives eMStage can be programmed in, for example, C so that we could more easily support eMStage.

 

Please let me know your thoughts and if you feel this would be a valuable free product that would improve sales and minimize support for simple problems that can frustrate our customers.

Why nobody ask the Advanced Services Team. We would also provide training in MCD.

I have two major customers using "gold" images. One uses a third party to maintain sparing. The other uses us to provide staging of devices upon repair. Both use MSP to apply changes to the gold image. This helps lessen the need for frequent updates.  Recently the changes in MAC addresses caused one of these customer to rebuild all his images. In fact, they will sometimes "reimage" a device via MSP as a last resort to correct issues with an application. The "Gold Image" approach is almost always asked about by customers. KEEP GOLD IMAGES  -  SELL MORE MSP

Most deployments employ, to some degree, a 'Gold' image, or some recovery installation build. The tools were not always defined, thus, one had to employ some degree of creativity in 'getting there'. In the past we fumbled our way through copy files, registry hacks, creative applets and startups.  We also had the ability to encapsulate this in an Application partition build, thus, a 'gold' image via a hex file was possible. If everyone employed an entity like MSP, I'd say that there is no real need for a 'Gold' image...not practical however, thus, the need to address how, and to what degree, a 'Gold' image is possible on the current devices.  If an SD is employed, it's simply creating an autorun with a bunch of CAB provisioning and application install files.  Without an SD, slightly more challenging...still possible though, as the Applicaition folder is still present in our devices. A single, comprehensive tool to accomplish this would be a blessing; however, unit specific limitations would have to be defined to determine the limits to an 'Gold' image. It will be a significant competitive advantage WHEN we provide a better and fully supported mechanism to do this!! Shall we say...PRD?

Great news, I have downloaded the beta OS package builder v1.56 and tested creating an image for the MC55 with some additional files in the application directory. All has worked fine. Part of me feels like an idiot that I did not know this already, but at least I know now. Problem is I know there are a lot of others that did not know this either. Lack of training?

one of the challenges is the Beta status of Osupdate Package Builder  and the lack of documentation. in the past put together this document which might help and is applicable for WM5.0 and WM6.1 / 6.5  devices. the next challenge is now the similar GAR deployement on CE 6.0  which is totally undocumented yet.

Along with the OS update Package builder, I think this one lacks documentation. I have been asked several times on both topics but never liked my answer. 

From the TA down under! Some excellent feedback from everyone, but unfortunately my initial question is still not answered. Might be a dumb question, but how do you build a gold image for an MC55 running WM6.1 (or WM6.5) - my understanding is that you require the DCP to be able to build a gold image, and Motorola does not release this anymore.

Hi Rob,

DCP is used just for CE5,CE4x,PPC200x devices. Beginning with WM5 and the new CE6 devices DCP is not used anymore. To Build a Gold Image you need the OS Package Builder which current Version 1.56.

The device type for your Package Builder project is "Magneto" for all Windows Mobile based devices which is the case of an MC55.

The Microsoft Update Loader cannot write customised application folder content. To get this to work the content of the application folder needs to be converted to an application.car file which can be done with the OS Package Builder. The OS Update tool first updates the application folder and boots than into the Microsoft Update Loader which will update the rest of the system. The content of the application.car file will be added to the application folder on the device. If you want to avoid having unnecessary files in the application folder you can add a custom option to your Package Builder Project like "-9\application\*.*". In some cases file cannot be deleted from the application folder because they are currently in use.

Hope this helps to create a Gold Image, Custom Image, Pre-Load Image :-)

Thomas

Gold Images (also called "Pre-Loaded" images) require some work to produce. And murphy's law operates on them with full force, ensuring that the harder the image is to buid or rebuild, the higher the likelihood that as soon as you have developed, tested and certified your "Gold" image, some bright lad will burst into your office yelling "stop the presses, I have just this one last change to make". In general, if you can build a "Self-Loading" image, you will be WAY, WAY better off.   A "Self-Loading" image is an image that is preloaded with a network setting and just enough "other stuff" to enable it to, on waking from the imaging process (or as soon as it finds itself in the presence of the preconfigured network), reach out to some SERVER and download the CURRENT application complement appropriate to its use. One way of looking at this is that a Self-Loading image is Golden - and STAYS Golden for a long time - because you don't have to rebuild it every time you need to update the software provisioning policy. Instead, you update the SERVER from which waking terminals pull down their software -- generally a LOT less work to maintain. It is possible to build such a Self-Loading image to use an AirBeam server but in light of the fact tha AirBeam is End-Of-Life it is not advisable. It is also possible to make waking terminals load themselves with the "latest, greatest" content using MSP3. This IS advisable.

The big advantage of a Gold Image is that all the devices are configured identically. if customers does not have MSP they can deploy the Gold Image via SD Card. Customers with an maintenance agreement plus the option to install a pre-load image often use Gold Images.  Disadvantage is that individual content like static ip addresses, device name, etc. cannot be part of a Gold Image and needs to be configured with other means like SymScript/EmScript. If I have customers using MSP than the Gold Image is my baseline configuration that contains a running MSP Agent and configured central relay server. Deploying the latest and greatest software configuration for the device even if there should be some individual configuration is with MSP really no big deal.

I am a big fan of "Gold" images. I have all my major customers on some form of gold image but as others have said, there isn't any one easy way to do this based on unique customer requirements. I have setup customers with a couple types of Gold images: 1a. Gold image that includes everything - this is a custom OS Image that includes all registry hacks, appcenter, CAB files, emulator and other misc. tidbits. It's a set image that doesn't often change and allows for easier troubleshooting (issues either affects all or none) while providing a very stable and predictable image. Within this type of image is an AirBeam client (no MSP) that checks in with FTP server on bootup just in case there is an updated component to this image to load (a new reg key or something that loads on top of image, not replaces image). This also provides very easy service from the depo as they load one standard image and ship the units out. 1b. Same as #1a but unique site or device requirements requires some initial user intervention like being prompted to enter a store # or device ID or something that equates to an internal piece of code calculating unique parameters (i.e. static IP address, unique Host address or whatever) 2. Gold image that includes only the required pieces - This is what Larry was referring to and is better labelled as a Pre-load image. It contains AppCenter with a locked down screen with 1 icon that says Device Setup (Rapid Deployment) and then utilizes MSP v3 to load up all components required for production. This provides all the benefits of #1 but allows the easier flexibility that MSP provides for more dynamic device loading. Unique Staging profiles can be used with this method for more site or unit specifc control but maintains the common image from our perspective, still controls OS etc. This is the best option in my mind but only if you've got MSP to utilize with it. Either way, yes Gold images are advised and any tools to make things easier are always welcomed!

Yes to the Gold (most of the time). For my major customers I strongly recommend a Golden image.  Why?  Because most of them run telnet and that is it.  They usually don't need or care for the headaches that come with upgrades or a mixed environment. If you have a customer with a 1000+ devices deployed that have several different version of software floating around.  Then when they do have a problem, you first have to find out what version of software that one devices was running and if any of the other devices with that version are having the same problem.  If you have a Golden Image, you know what version of software is running.  This makes it a lot easier to figure out if it is a device issue, configuration issue, or a global software issue. The one thing I do tell customers with Golden Images is to keep testing their software with our latest released versions of software.  That way if they do need to upgrade for some reason in the future they are prepared.

No Motorola doesn’t have a unified approach or an answer to the Golden Image question and I don’t think they can.  Every customer is different on whether that is the applications they run or the way they manage their devices and thus a blanket answer of whether a Golden Image is right or wrong and how to implement one needs to be done on a customer by project basis.

Gold Images (also called "Pre-Loaded" images) require some work to produce. And murphy's law operates on them with full force, ensuring that the harder the image is to buid or rebuild, the higher the likelihood that as soon as you have developed, tested and certified your "Gold" image, some bright lad will burst into your office yelling "stop the presses, I have just this one last change to make". In general, if you can build a "Self-Loading" image, you will be WAY, WAY better off.   A "Self-Loading" image is an image that is preloaded with a network setting and just enough "other stuff" to enable it to, on waking from the imaging process (or as soon as it finds itself in the presence of the preconfigured network), reach out to some SERVER and download the CURRENT application complement appropriate to its use. One way of looking at this is that a Self-Loading image is Golden - and STAYS Golden for a long time - because you don't have to rebuild it every time you need to update the software provisioning policy. Instead, you update the SERVER from which waking terminals pull down their software -- generally a LOT less work to maintain. It is possible to build such a Self-Loading image to use an AirBeam server but in light of the fact tha AirBeam is End-Of-Life it is not advisable. It is also possible to make waking terminals load themselves with the "latest, greatest" content using MSP3. This IS advisable.

Gold Images (also called "Pre-Loaded" images) require some work to produce. And murphy's law operates on them with full force, ensuring that the harder the image is to buid or rebuild, the higher the likelihood that as soon as you have developed, tested and certified your "Gold" image, some bright lad will burst into your office yelling "stop the presses, I have just this one last change to make". In general, if you can build a "Self-Loading" image, you will be WAY, WAY better off.   A "Self-Loading" image is an image that is preloaded with a network setting and just enough "other stuff" to enable it to, on waking from the imaging process (or as soon as it finds itself in the presence of the preconfigured network), reach out to some SERVER and download the CURRENT application complement appropriate to its use. One way of looking at this is that a Self-Loading image is Golden - and STAYS Golden for a long time - because you don't have to rebuild it every time you need to update the software provisioning policy. Instead, you update the SERVER from which waking terminals pull down their software -- generally a LOT less work to maintain. It is possible to build such a Self-Loading image to use an AirBeam server but in light of the fact tha AirBeam is End-Of-Life it is not advisable. It is also possible to make waking terminals load themselves with the "latest, greatest" content using MSP3. This IS advisable.

Yes, many customers have gold builds – Those with contracts whereby we stage there devices for them certainly have gold builds, it defines what software etc.. for that customer and its normally in the contract for them to supply a gold build.

 

Our currently supported tools do not address staging issues, currently we have startup control – fine for a few cabs and starting apps but that’s all.  MSP can do some/much of this but not all customers use MSP

 

Many customers have complex staging requirements – that require a lot more functionality than we currently offer.

 

Many customers use SymScript as it allows them to fulfil there staging requirements.  So its either use a script or the customer must write some code to perform this functionality – many customers will not do this due to cost, ownership etc. 

 

An example might be customer uses a third party application – loaded as CAB – the CAB as part of the installation requests that you enter some data – So at this point without a script you would typically have to manually enter it – error prone etc.. But with a script you can start the CAB, wait for the window to be displayed then enter the data as if the user entered it – so you can make the process automated – This is just one example.