I successfully registered an Android device to EMM.
Then I did a factory reset and registered it again.
Now I have the same device listed twice in my Device Management.
First thing: Is this behaviour wanted? I think there should be a rule that checks the IMEI and replaces the old object with the newly registered one.
Second thing: How do I get rid of the old object?
What if a phone gets destroyed and I can't unregister it unit-side?
Thanks in advance for any reply.
Conrad
We cann't replace the old device object with the new one because it might cause issues in shared-device scenarios (mostly COPE devices) where several users have access to the same device. So current user of the device must be able to login to EMM without removing the other owners' data. However I think this behavior must be changed to detect the Active device instance / owner from the same device instances and show it instead of showing multiple instances of the same device.
You can not delete the device from the EMM server by removing the registration from the client side. Only way to remove it would be manually removing the database table entry in the "devices" table of EMM database.
I had this problem, and found a (complicated) way to remove these zombie devices.
First of all stop your EMM server with a command like :
# /opt/wso2emm-1.1.0/bin/wso2server.sh stop
Then backup your databases:
# tar -zcvf /root/emm_db_backup.tar.gz /opt/wso2emm-1.1.0/repository/database/
Then start the H2 RDBMS:
java -cp /opt/wso2emm-1.1.0/repository/components/plugins/h2*.jar org.h2.tools.Server -web -webAllowOthers
Now, point your browser to http://YOUR_SERVER_IP:8082
Load the database with the JDBC URL:
jdbc:h2:/opt/wso2emm-1.1.0/repository/database/WSO2EMM_DB
(default User Name and Password are both wsocarbon)
You can list the devices with SELECT * FROM DEVICES
Delete the device by ID with: (change the 1 to whatever zombie device you want to get rid of)
DELETE FROM DEVICES
WHERE ID=1;
You're done! (well, after you stop H2 and start your server again)
Related
Working in low bandwidth environments sometimes I need to share a text console (TTY) screen with a co-worker. I often use the screen(1) tool to keep multiple windows open in the same SSH connection and be able to reconnect and continue where I left off, when my connections drop due to bad internet. I wonder if we could not attach multiple SSH sessions / TTYs to the same screen(1) session so that my co-worker(s) and I can both use the same console? It should be possible, but is it?
The answer is as follows:
first screen session is started with
screen ...
then from another console as the same user someone else can attach to the same screen session with
screen -x
And then they can both work, one thing typed by one will be visible by both, etc.
Note: if the screen session has multiple windows, then each attached terminal can switch to a different window independently.
A little new to NRF52, so please pardon if this turns out to be a noob question. I'm using nrf52832 as a peripheral and loading the standard SDK peripheral example of GATTS ( any other does result in the same).
After configuring that device i try to connect my phone to it , which happens succesfully. But after unpairing my phone and trying to configuring again my phone cant pair with the device.
Phone shows:
Could'nt pair .Check settings of this device.
Sniffer shows:
Rcvd pairing failed: Pairing not supported.
I do understand that some thing is getting stored in persistent memory. So how do i remove it or how do i load that data again.
Mobile app Logs:
Error 22 (0x16) GATT_CONN TERMINATE LOCAL HOST
Sounds like you've triggered one of the default security features of the nRF.
The nRF knows it has an encryption key with the phone (as it's been paired before), but the phone doesn't know the key (because you unpaired it and it deleted the key), so the nRF assumes someone is trying to spoof the real phone and drops the connection as defense.
Not sure which nRF SDK you're using, but if you search for peer_manager in the initialisation routine you should see an option to allow keys to be over-written.
Here's the relivent docs. One quick-fix, if security isn't a concern, is to delete all bonding info on the nRF with pm_peers_delete()
I have trouble with one of my devices (Tracker dongle) communicating with Cumulocity. I used the Device Registration interface to register its IMEI. Then I accepted it in the same interface when it first connected. But now the tracker-agent I deployed is continually logging:
c.t.d.DeviceBootstrapProcessor : Start bootstrapping:
(DEVICE_IMEI)
And I got nothing arriving on Cumulocity. So I'm guessing it's stuck trying to retreive the device credentials? (Cf. DeviceBootstrapProcessor.tryAccessDeviceCredentials). I have another device of the same type which worcks just fine in the same configuration and I can't tell what's the difference between the two. Is there a step I'm missing to correctly register a device?
The tracker-agent has an additional registration for itself. It is once per tenant and automatically triggers after registering the first tracker device.
What you need to do is register the agent (via device registration) with the following ID:
tracker-agent-{tenant}
(replace {tenant} with the tenant you want do register the agent). This needs do be done once per tenant to allow the tracker agent to create devices and data.
My app uses iCloud (key-value store) to sync an unique id between multiple devices. This works accept at the point were it really has to work, at the first launch of the app. It looks like the device isn't yet familiar with the values from iCloud at first launch, only after the app is installed and has been running for a while.
I check for the iCloud value in the viewDidLoad function on main view of the app.
So, my questions:
Is this the expected behavior?
If yes, is there another solution?
Could it be the case this is only a problem when running from Xcode, not the shipping version? If so, how to test?
Thanks!
Jasper
I had a similar issue where the NSUbiquitousKeyValueStoreDidChangeExternallyNotification wasn't triggering on the first launch after install, no matter how long I waited. Setting an initial key in the NSUBiquitousKeyValueStore seemed to solve this.
Immediately after adding the observer to the default store, I call:
[[NSUbiquitousKeyValueStore defaultStore] setString:#"testValue" forKey:#"testKey"];
[[NSUbiquitousKeyValueStore defaultStore] synchronize];
I use different keys (i.e. not testKey) for the actual data I want to sync.
When you first run an iCloud enabled App it has to pull all the data from Apple servers. The time it takes to do so depends on many things like what kind of network you're currently on (Edge, 3G, GPRS, WLAN). It also depends on how much traffic the iCloud server currently has to handle so the request to the iCloud server may take a few more seconds, no matter what type of network connectivity you have.
To sum it up: Yes, it sounds absolutely normal.
If running your App depends on those settings consider implementing a "Wait" or "Loading" view that stays on the screen as long as it takes for the App to perform a initial synch and load all needed data from the cloud. To not block the UI forever also implement a timeout for this view (if iCloud data not loaded within X seconds, dismiss the view and notify user).
You have no guarantee NSUbiquitousKeyValueStore would have finished its first synchronization as your app is launched for the first time. (In fact, on iOS 5, it's often starting to sync as you launch your app for the first time).
There is no way to know if the first initial sync has already happened, is ongoing or has finished. You can (in fact should) subscribe to NSUbiquitousKeyValueStoreDidChangeExternallyNotification. The trick is that if your store is empty on the iCloud server, you won't get any notification after the initial sync (since your local store is empty and the cloud store is empty as well, nothing really changed "externally" after the initial sync…)
Normally, you should not rely on the initial sync being done.
Be optimist at launch, even if your store is empty, push your values (e.g. your unique id) right away. If the initial sync happens concurrently or after and there is already some value on the server, your local values will be reset to the server values and you will get the NSUbiquitousKeyValueStoreDidChangeExternallyNotification notification with the NSUbiquitousKeyValueStoreInitialSyncChange reason.
Finally, if you really think knowing about the initial sync being completed or not, please file a bug to bugreport.apple.com and explain why you really need that.
Hello i have a question,
i write a requirement specification.
there is a system, where more than one person interacts with,
and i want to describe what happens when one person quits the interaction.
I don't know how exactly a mulituser systems works,
i guess the system creates an instance (?), and when the user finished it get closed again?
but the system as such still runs (for sure).
how can i discribe that ... issue correctly? ( does it work like i guessed?)
thanks in davance
I'd say that the system listen on two different things :
a message (interaction) from one of the connected users
a login message from a new user
This behavior is parametrized by the number of connected users. In the limit case where all connected users disconnect, the system does not wait anything from connected users, but keep listening on new connections.