has anyone been able to remove a banned flag for an iPad/iPhone user in Traveler ? We updated the traveler and domino server to 8.5.2 and had to delete a user that was configured with an iPad during 8.5.1. However, we need to get the active synch up to date and cannot get past the final authentication stage in setting up the profile. This was a working iPad with Notes. Able to start the whole config process but get anauthentication error when finishing up the last step (enter a password.)
I did issue :
tell traveler security flagsRemove all Appxxxxxxxxxxxx
Subject: RE: Traveler 8.5.2 Authentication and banned user
There have been a couple of PMRs on this same issue.
The issue is that the “Prohibit devices incapable of security enablement” has been checked. The existing devices are only using ActiveSync 2.5 and cannot support all of the security settings because many of them are only in ActiveSync 12.1. The devices get “banned” and cannot log into the system to switch to AS 12.1 and get the banned removed.
Allowing the existing devices that got banned back into the system can be done in at least 3 ways, but APAR LO55130 is definitely the easiest. To get the APAR, you will have to open a PMR and L2 can provide the APAR fix once it is available (it is still being internally tested).
Here are three different sets of steps for the Admin to use depending on how the Admin wants to allow banned devices back into Traveler:
A. Server with APAR LO55130 - Device power off and power on.
Tell the device users to reboot their device(s). Reboot means power completely off by holding the power button and sliding it off and then power on with the power button (not just turning the screen off and on) . Without powering off and back on, the device will continue to use the old security protocol instead of the new protocol which is needed. Traveler tells the device to switch to the new protocol, but the Apple device ignores that request and continues to use the old protocol until the device is rebooted.
B. Current server (no APAR LO55130) - Clean up and reinstall the device accounts (Apple profile or manual) as needed…
On the device, remove the account (Apple profile or manual).
On the server, “tell traveler delete ”.
On the server, “tell traveler security delete ”.
On the device, reinstall the account.
C. Current server (no APAR LO55130) - Turn off “Prohibit devices incapable of security enablement” until all the devices have upgraded.
Shutdown Traveler (tell traveler shutdown)
Open the Default Settings or Policy definition and uncheck “Prohibit devices incapable of security enablement”.
Start Traveler (load traveler). When Traveler loads, it will prime sync each device and remove the banned flags allowing the devices to access the system.
Tell the device users to reboot their device(s). Reboot means power completely off by holding the power button and sliding it off and then power on with the power button (not just turning the screen off and on) .
After the device has rebooted and synced with the server, it needs to do another configuration with the server. To do this, issue “tell traveler push flagsadd serviceability configGet ” for each device in the server console.
The device will do the configuration steps when it next syncs or connects to push.
Confirm the device is fully compliant by looking in LotusTraveler.nsf or running the show tell command (tell traveler show ). In LotusTraveler.nsf, you are looking for the value in the Security Policy column in the Device Security view. In the show tell command output, you are looking for the Security Policy Status value. If the value is “Compliant - limited”, the device has not upgraded yet. If the value is “Compliant”, then the device is upgraded.
Once all of the devices are upgraded (Compliant instead of Compliant - limited), turn “Prohibit devices incapable of security enablement” back on.
Note: any new devices will start with the full settings, so these steps are only necessary for existing devices.
This should be in the readme for 8.5.2 I had (2) iPad users on 8.5.1 (when iPad was unofficially supported.) I deleted the user with tell traveler delete but no where did I find or see anything on tell traveler security delete . Seems like this is the way to remove the “banned” flag from traveler ?
Interestingly, when I do a tell traveler delete the server tells me the deviceID is invalid. But if I do a tell traveler security delete the server takes the command sucessfully and now when I issue tell traveler security status shows No records.
This procedure needs to be documented in help for 8.5.2.
Forgot to mention, the second iPad user who was initially configured with 8.5.1 eventually did upgrade sucessfully and is now compliant. This wihtout any intervention. So it looks like the Apple HW is capable of picking up the return code to update the ActiveSynch version. Unless there are just some old iPad builds the were problems but sold.
There are some sequences of events where the iPad will get through without getting banned. But, it is easier just to tell people the steps that will work all the time as the timing of the other steps can be very tricky and only make it more confusing. The device periodically does an OPTIONS request, but we do not have access to the device code to know when that is. It appears to be somewhat random unless you go into the account settings and touch one of the settings. In any case, I know that it is possible to not get banned, but a majority of devices seem to get banned.
Also, the documentation will be updated with the APAR information and the steps. This migration issue was not caught in any testing or by any beta customers.
You should NOT be deleting records from LotusTraveler.nsf. That does not delete the user or the security record. The only actions you can take are the buttons at the top such as wipe or deny access. The other actions are available view tell commands on the console. LotusTraveler.nsf is “read-only” except for those actions. It reflects the state the Traveler has stored internally, but any data manipulation needs to be done through the buttons or tell commands. This is in the 8.5.2 documentation as others have tried this only to find that deleting the records did not do what they thought (it only deletes from the nsf and not from Traveler).