After we recently upgraded our environment to Ivanti Workspace Control 10.12.0.0, we suddenly encountered issues with Citrix Published Applications. Users trying to launch a published application received an error “Application can’t be started…(Instant Passthru could not be resolved)
Although we had not made any changes to the Citrix XenApp Publishing integration within the Ivanti Console, we did check the configuration completely. Everything was configured as Ivanti says it should be set up.
Cause the update of our last golden image only updated Ivanti Workspace Control, we decided to downgrade the agent from 10.12.0.0 to 10.11.10.0, the version we were previously using. And yes, suddenly everything was working properly again.
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
Configuration and state
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!
During regular maintenance at a customer we noticed the Ivanti WorkSpace Control logging database was getting quite big. The logging database had reached a size of more than 1TB, something of which the cause was not immediately clear. Sure they had lots of users and were keeping lots of auditing data, but the increase in database size couldn’t be related to additional users or something else.
We contacted Ivanti Support to investigate the huge increase in logging database size. They told me about a useful tool called “Workspace Manager Logging Management Tool“. The tool was created by a former employee Patrick van Grinsven. Soon it became clear what exactly was using so much space within the logging database.
Prior to Windows 10 (build 1607) Sticky Notes was a “Desktop App”, for which it was quite easy to roam all user settings and notes. But since the Windows 10 anniversary update Sticky Notes is available as a “Windows App” (Universal App). This creates a new challenge.
We have to make sure that Sticky Notes settings and notes, which a created by the users are being roamed. In case that roaming profiles are being used, this won’t be very challenging, because the whole user profile will be stored soon as an user logs off. However when local or mandatory profiles are used, in combination with a Zero Profile technology, like the technology offered by Ivanti Workspace Control (formerly RES Workspace Manager), some challenges lie ahead.