#Ivanti user workspace manager ports update#
Update – I’ve had a good long think about version 8, and I now think you could maybe do this with a “big bang” approach instead…see the “Version 8 Considerations” section near the end. Otherwise – you have to copy the data manually across using Personalization Analysis, and personally, I’d rather just start the users with brand new profiles then spend the time to do that. I am reliably informed that Ivanti support may be able to provide a script that can help with this, so if you can get hold of it, this may help you out a bit here. When the user is moved from the PMO to the IMO group, you will need to manually migrate the Personalization data from the PMO Personalization Group into the IMO Personalization Group. If you are still on version 8.x – this is a major stumbling block. If you’re on version 10.x or higher, than all is good – Personalization data is now shared between Personalization Groups ( see this article for more information about this – logon required). This process relies on the ability to move data from one Personalization Group to another within Ivanti/AppSense. IMO – Intermediate Method of Operation, referring to the intermediate area that users will need to access to trigger the migrationįMO – Future Method of Operation, referring to the new image with FSLogix Profile Containers being used for profiles Pre-requisites Ivanti/AppSense version PMO – Present Method of Operation, referring to the existing solution with Ivanti/AppSense being used for profiles We are going to use the following acronyms extensively:.
#Ivanti user workspace manager ports windows#
If you’re using Ivanti with local profiles, you may be able to skip the need for the intermediate area, but generally in RDSH or VDI environments local profiles are uncommon (unless you’re doing pooled non-persistent).Īlso, we have performed the testing and demoing of this on Citrix Virtual Apps, but the principles should work equally well for other setups – whether these be VMware, Parallels, Windows Virtual Desktop, physical machines, cloud-hosted devices, etc. The reason for this is because most people use Ivanti Personalization Server combined with mandatory profiles, and we can’t migrate data out of mandatory profiles (because they’re utterly non-persistent). We need our existing Ivanti UWM-managed infrastructure, we need our new FSLogix-managed infrastructure, and we also need an intermediate area which has both Ivanti and FSLogix installed to perform the migration. However, I have used this in the wild with success on a few occasions now, so I think this should work for you, if you can follow the same process (and you’re always welcome to drop me an email and get me to do it for you, if you have any problems).įirstly, we need a three-tiered setup to accommodate this. So the process I am using involves a bit more fudging than you may like. If I was someone like Jim Moyle (or one of the many other God-level scripters out there in the EUC community), I would just write a script to pull the information straight out of the SQL database and build a new profile. Let’s just start by saying that the migration process isn’t particularly straightforward. I still think DesktopNow has its place – for fine-grained control of the user environment, you can’t go far wrong – but as I have had to perform migrations for a couple of customers recently, I thought I would write up the process I used to do it.
Whilst a very fine product (I cut my blogging teeth writing about AppSense, so still have a great deal of experience with it and fondness for it), there are a lot of people moving away from it towards the like of FSLogix Profile Containers – mainly purely from a cost perspective. Ivanti User Workspace Manager (or AppSense DesktopNow) has a product called Environment Manager Personalization Server that is used for storing users’ profile information in an SQL database. Migrating DesktopNow to FSLogix has always been fiddly.
0 kommentar(er)
