Rudra Thanks for the information. It´s really useful.

Allan,
OK, check me.

1. Create Condition (CorePing)

Adapter Contraint: Constrain based on continuously Unconnected adapter WLAN 2 Checks OR 4 Hours Target Contraint: Constrain based on continuously Unpingable target 172.30.1.1 5 Checks OR 4 Hours

2. Create Setting (NoCorePing)

Scenario Type: Conditional Scenario Action: Lock Condition: CorePing

LockAndWipe 2.30 already exists on the Target MC75.

Do I push setting 'NoCorePing' as a Policy? Do I create a fresh Bundle with 'LockAndWipe' and 'NoCorePing' in a Policy? What a mess?!? Thank You Brad

Brad; You actually are right in the ballpark.  I usually don't specify BOTH Unconnected Adapter and Unpingable Target since the target will by definition be Unpingable if the Adapter is Unconnected.  But I don't think it will hurt.  I also usually specify only Checks or Time but not both.  Using checks makes it dependent on your check-in time.  Using time makes it absolute, but since it will only be checked on check-in, using time is not totally independent of check-in time.

You can choose to deploy the Control.LockAndWipe Settings in the same Bundle as the LockAndWipe Package, as long as the Package comes BEFORE the Settings.  I usually include the LockAndWipe Package as the FIRST Step in EVERY Bundle that includes a Control.LockAndWipe Settings, just to be sure - if its already there, it will be skipped.

Deploy the Bundle to the devices via a Policy.  When the MSP Agent checks in after the Package + Settings are installed, LockAndWipe will get invoked and will evalute the Conditions and decide if it is time to Lock.  Then interrupt the WLAN and wait and it should Lock when the Conditions have been met.  For initial testing, it can be handy to use a Condition that is met sooner.

Allan

Allan, Which condition would I use for sustained inability to PING?  Would pinging cause a EVDO or WLAN connection to be established?  I suppose I would have to ping a private address inside our VPN tunnel not to inadvertinley wake the WLAN interface.  Would this only be a PING when the control module is activated?  Would there be a running count of PING failures?  Wait, didn't I read somewhere that MSP (30Agent) won't dial a EVDO connection?!?

Thanks Brad

Hello Pablo,

 

This post is to answer the 'configuration to be applied for using the LockandWipe'.

Please see the steps.

 

Lockandwipe requires the following to be pushed to the device in order including in a Bundle:

 

1.       LockandWipe.apf

2.       ld.apf

3.       UsrrAuthentication settings

 

1.       LockandWipe you will find in Library->Packages.

2.       Steps for creating the ld.apf file

 

In order to test the UserAuthentication Control Module, as part of pre-requisite following must be done:

1. Login to the MSP Server as Administrator through Remote Desktop Connection

2. On the Desktop, create a text file with the name "ld.txt". This text file will contain the Username and/or Password pair, each being separated by a comma (,). This text file is called the UserAuthentication file. A sample of this file is attached and is named "ld.txt"

3. ld.txt should contain the username and/or password in the following format:

motorola,motorola         // in this case Username is motorola and Password is also

symbol,SYMBOL           //in this case Username is symbol and Password is SYMBOL

4. Once the "ld.txt" is created on MSP sever, it has to be encrypted since it will be in the plain text format. Next step tells us how to encrypt the file.

5. On the same MSP server, click on Start button-> All Programs-> Motorola MSP-> Launch EncryptUserFile.exe

6. A window similar to the default Windows Command Prompt opens

7. On this window, you get to see a prompt with the following text:

Please enter the file name:

At this prompt, enter the path (including the filename & without extension) at which the ld.txt file is present.

In our case since we created the file on desktop, the value to be entered will be as below:

Please enter the file name: C:\DocumentsandSettings\Administrator\Desktop\ld

8. On hitting Enter, the window closes and a new file by name "ld.aut" will be created at the same location of the

"ld.txt" file. "ld.aut" will be an encrypted file and will not be in human readable format.

9. Using the MSP package builder, create a package ld.apf within MSP for each unique User Credentials File. The required path and file name of the User Credentials File must be “\Application\MSP\Control\LockAndWipe\ld.aut”.

10. Once the package, ld.apf, is created, it has to be uploaded in to MSP by navigating to Library-> Packages page.

 

3.       Steps for creating the user Authentication settings

 

UserAuth setting creation:

1. Login to MSP console as Administartor

2. Navigate to Library-> Settings and click on Create

3. Select Control.UserAuth.setting.xml from the drop down list

4. Enter the name and click on Next

5. Select "Authentication WILL be Used" option for the "Authentication:" attribute

6. Select "Prompt for entry of a Password" option for the "Password Prompt:" attribute

7. Select "Do NOT allow barcode scanning of username and password" option for the "Allow Barcode Scanning:" attribute

8. For the "Login Button text:" field, enter the text as "login"

9. Leave the rest all paramaters as default and click on Finish button.

  After doing all the 3 steps as mentioned you will need to create a bundle and add all the 3 packages and settings. Later through provisioning, include the bundle in the policy and apply it on the device.

Note: This is one such configuration setting for using the locking the device. You could explore some other options from the settings file. I have also added a text file as an example. Please let me know if it helps.

Brad; The Connectivity Condition supports the ability to Contrain based on continuously pingable target".   No, nothing in MSP causes an EVDO connection to be established, including this Condition.  All MSP components rely on there being an existing connection, either established by another application or by configuring the WWAN connection as "Always Connected".  When used, this Condition will cause a PING to go out every time the device checks-in, assuming that a connection is available.  If no connection is available, then the PING will fail, and be counted towards the target being considered unpingable.  When consecutive PINGs fail for the specified time or count, then the Condition will trigger. It had slipped my mind that you were using WWAN (although now that I think about it, of course you are).  In most cases, WWAN deployments probably will not have an easy time using Connectivity to detect devices that may need to be locked.  I am not saying it is impossible, just that it is likely difficult and may not be practical in every case.  Ultimately, what I said before is true "it can be a challenge to decide what Conditions that can be tested ON THE DEVICE best represent when you consider the device to be lost or stolen".  What it comes down to is, ignoring MSP, you need to decide what real-world testable criteria exist that indicate the circumstances you want to detect.  If you can't do that, then there is likely little MSP can do for you.  If you can do that, then it makes sense to try and figure out how to get MSP to detect those circumstances, which may or may not be possible or practical. Allan

Brad; If the device is not checking in with MSP then there is nothing that MSP can do to the device.  MSP could send a Job, but it would not take effect unless/until the device checks in with the Relay Server and picks up and executes that Job.  If the device is REALLY missing or stolen, then that likley won't happen.  You might want to send the Job anyway, just in case the device shows up, since then it WILL get locked or wiped and you might hear about it when someone tries to use it. The best way to protect a device from being used if it is lost or stolen is to configure LockAndWipe with Conditions that will cause it to Lock or Wipe ITSELF, without interaction with the MSP Server.  The LockAndWipe Control Module supports that, but the tricky part is deciding what Conditions to use.  Every situation is generally different and it can be a challenge to decide what Conditions that can be tested ON THE DEVICE best represent when you consider the device to be lost or stolen.  Most customers I have seen end up using sustained inability to reach some server as the trigger (continuously unpingable target address for X time). Allan

Do you have a configuration example of how to use LockandWipe?