Since quite some time Office has a AutoRecover feature which saves your documents every couple minutes. A super handy function to prevent you from losing a lot of work. By default Office saves an AutoRecover file every 10 minutes, for example in Word this is the default location : %AppData%\Microsoft\Word. In an enterprise environment however, the AutoRecover file location is often adjusted. For example it’s redirect to the users homedrive, in my case “H:\My Documents\AutoRecover”.
An external software supplier wanted to make a new app available for a selected group of smartphones. We were asked if it would be possible to retrieve the smartphone from the XenMobile database. New smartphones added to the delivery group would be detected automatically. Since XenMobile has a REST API, this didn’t seem like a problem at first. We made the REST API available to our software supplier, after which they created a link between their backend and our On-Prem XenMobile environment based on the Citrix XenMobile REST API documentation
At first everything seemed to work perfectly and our software supplier thought they saw all our devices. After some time we noticed that there was a difference between the devices visible in the XenMobile console (Web GUI) and the devices that our software supplier saw through the REST API. Based on the query that was used in the REST API, we then did some testing ourselves using Postman, in the hope of uncovering the difference in devices.
Read More →Life Cycle management occasionally causes SQL servers to be replaced and databases to be moved to new servers. As a result, the Ivanti WorkSpace Control datastores have to be moved. Now this does not seem very complex at first, but if the environment uses a primary and secondary datastore, you have to deal with some extra challenges. The IWC datastore contains three components
Out of the box the data is stored in the primary datastore, but the logging and usage tracking data can also be stored in the secondary datastore. This ensures that the configuration datastore does not explode.
Ivanti has a nice support article in which they exactly describe how you can move both datastores to a new database server (SQL in my case). Basically, you merge the secondary and primary datastore again, migrate the primary datastore to the new database server and split the logging and usage tracking from the primary to the secondary datastore.
This all sounds very simple, but what if your secondary datastore is 600GB in size? Putting these together will take forever, not to mention other challenges. Consider, for example, the sizing of the primary datastore, can it store so much extra data? In this case you actually want to migrate the primary and secondary datastore to the new SQL environment and simply change the database connection string within the Ivanti WorkSpace Control console. Although there is no support article how this can be accomplished, luckily there is a way to do this in a supported way!
Read More →