Recently 90 days occured since we went live and the decommision batch was executed which have decommision approzimately 3000 devices. On what bases mobilefirst decomission these devices? Does it completely disables user access? If so how can these devices be enabled again? How to disable the decommision batch process.
Mobilefirst 7.1 - What does decommision process does? How to undo decommisioned devices
111 Views Asked by MobileFirst Developer At
1
There are 1 best solutions below
Related Questions in IBM-MOBILEFIRST
- How to display a Google Document inline image on HTML page?
- How to add Named Ranges to sub-paragraph elements in Google apps-script
- Output API data to a csv file
- automated email sending - variable in Htmlbody
- union data in multiple tabs
- How to real-time monitor the emails?
- How to pass function arguments to another function?
- Google sheers: On edit event trigger
- TypeError: Cannot read property "length" from undefined
- How to upload any file to FTP Server using Google Apps Script
Related Questions in MOBILEFIRST-SERVER
- How to display a Google Document inline image on HTML page?
- How to add Named Ranges to sub-paragraph elements in Google apps-script
- Output API data to a csv file
- automated email sending - variable in Htmlbody
- union data in multiple tabs
- How to real-time monitor the emails?
- How to pass function arguments to another function?
- Google sheers: On edit event trigger
- TypeError: Cannot read property "length" from undefined
- How to upload any file to FTP Server using Google Apps Script
Trending Questions
- UIImageView Frame Doesn't Reflect Constraints
- Is it possible to use adb commands to click on a view by finding its ID?
- How to create a new web character symbol recognizable by html/javascript?
- Why isn't my CSS3 animation smooth in Google Chrome (but very smooth on other browsers)?
- Heap Gives Page Fault
- Connect ffmpeg to Visual Studio 2008
- Both Object- and ValueAnimator jumps when Duration is set above API LvL 24
- How to avoid default initialization of objects in std::vector?
- second argument of the command line arguments in a format other than char** argv or char* argv[]
- How to improve efficiency of algorithm which generates next lexicographic permutation?
- Navigating to the another actvity app getting crash in android
- How to read the particular message format in android and store in sqlite database?
- Resetting inventory status after order is cancelled
- Efficiently compute powers of X in SSE/AVX
- Insert into an external database using ajax and php : POST 500 (Internal Server Error)
Popular # Hahtags
Popular Questions
- How do I undo the most recent local commits in Git?
- How can I remove a specific item from an array in JavaScript?
- How do I delete a Git branch locally and remotely?
- Find all files containing a specific text (string) on Linux?
- How do I revert a Git repository to a previous commit?
- How do I create an HTML button that acts like a link?
- How do I check out a remote Git branch?
- How do I force "git pull" to overwrite local files?
- How do I list all files of a directory?
- How to check whether a string contains a substring in JavaScript?
- How do I redirect to another webpage?
- How can I iterate over rows in a Pandas DataFrame?
- How do I convert a String to an int in Java?
- Does Python have a string 'contains' substring method?
- How do I check if a string contains a specific word?
The decommission process marks an inactive device as "Inactive" in the DEVICES table in the runtime database. A device is considered to be "inactive" if it has not connected to the server in a certain length of time, defined by the "wl.device.decommission.when" JNDI property. After a further period of inactivity, defined by the "wl.device.archiveDecommissioned.when" JNDI property, an inactive device is removed from the DEVICES table entirely, and placed into an archive file. The default value of both of these properties is 90 days - so, a device is noted as "Inactive" in the DEVICES table after 90 days of inactivity, and it is removed from the table entirely after a further 90 days of inactivity (unless you have changed the values of these properties to specify different inactivity times). A device that has been decommissioned would be marked as "Active" again (or put back into the DEVICES table, if it's already been archived) simply by accessing the server again, unless the device access management features are enabled (see details below). If device access management is enabled, and the inactive device has not yet been archived, the server administrator will need to manually set an inactive device back to "active" in the MobileFirst Operations Console before access is re-enabled.
This is used primarily for license tracking, and to support the device access management features (if you are using them - the ability to disable a device from accessing the server via the MobileFirst Operations Console). It does not affect whether or not a device can access the server if the device access management features are not being used. For further information about the relevant JNDI properties and how they are used see the documentation, here:
License tracking
and here:
JNDI environment entries for MobileFirst projects in production
and here:
Mobile application management
If you have not licensed the MobileFirst Platform based on number of Client Devices or Addressable Devices (a typical B2C case), and you have no need for the device access management features, you may want to disable device tracking entirely to improve performance, by setting the JNDI property "wl.device.tracking.enabled" to "false". By default, "wl.device.tracking.enabled" is set to "true", and "wl.device.enableAccessManagement" (which enables the device access management features) is set to "false".