due to the EoL of EEPC 6.x we are in the need of Upgrading round about 1.000 Notebooks. In our testlab everthing works fine but the transfer of the UserAssignemnts for encrypted Notebooks.
old ePO Server: 4.5.6 - EoL end of this year
EEPC 18.104.22.1684 - EoL middle of april 2014
new ePO Server 4.6.6
Does anyone have a clue for this problem?
The transfer itself works like a charm for Server, Workstations and Notebooks. So everything looks fine but when transferring encrypted Notebooks we are encountering the problem there is no DB-Transfer of UserAssignement. How are we supposed to reassign Users for more than 1.000 Notebooks? Does anyone have a clue for this without manual reassignement?
moving users to a new EPO server has never been supported - the usual process is to upgrade your existing server and keep the DB, not move everything to a new one.
there are several reasons for building up a whole new environment.
- Moving from Windows Server 2003 32bit to Windows Server 2008 64bit, DNS/IP-Change, SQL 2003 32bit to SQL 2008 64bit
- Bug in EEPC 6.x were more users added then it was intended (and no, McAfee couldn`t solve this one. It isunpredictable and is still happening)
- Complete Review of ePO Layout, structure and permission settings due to severe changes in the past years which had been left out of implementing in ePO
- support of transfer Systems from one to another ePO-Server
And I am just asking for a non "quick and dirty" solution. If there is one of course.
edited on 19.12.13 07:34:22 CST
The users encryption keys are locked to the EPO db you are using, there's no current way of moving them to a new DB that I am aware of.
as far as I can see everything hangs up to the AutoID and I can fully understand, this is quite a delicate task in integrating this part to the transfer mechanismen. But on the other hand it is quite a flaw for not considering such situations in my personal opinion. Please don´t take this personal (I really like your tools, knowledge and your efforts @ EEPC) but I have to consider what to do with our encrypted Notebooks and as far as I can see this will not be funny...
The helping hand to this situation maybe the use of "Add local domain users" functionality. It's true that user assigments are lost during moving systems from one ePO to another, but just like recover recovery keys, users can be also resend to ePO. However it works differently on Windows 7 and XP system, where on Win7 it seems to be sent after first or subsequent ASCI (after migration to new ePO) and on XP relogon is required (restart will involve machine recovery).
Two main drawbacks of this approach is that passwords get reset to default and SSO is not working for the first time after user machine migration. And unfortunately this have to be done proceduraly by informing users about such change.
Another way can be the use of ePO API scripting to assign users, however because of ePO 4.5 it will be hard to collect UMA list and eventually it also led to the same situation with default passwords.
Concluding if you would like to do this in supported way currently there is no way to not bother users and have lot of administrative work.
would the migrate tool for ePO 5.0.1 work in this scenario as mentioned by Joe and further down RGC?
I'm struck in a simlar situation- but now have two ePO serverswith encrypted machines! its all turning into a nightmare.
how did you the migration? Did you set up a new (fresh) ePO 4.6 server with new database and then transfered clients to new ePO?
How about doing the upgrade this way: http://kc.mcafee.com/corporate/index?page=content&id=KB71078
btw: I think "somewhere" - maybe it was in the ePO 5.1(?) docu - there is sth mentioned about moving encrypted clients will result in loss of encryption key (or maybe in the recovery key)?
W3K3 32bit, SLQ2005 32 bit, ePO 4.5.6, singel Server
W3K8 64bit, SLQ2008 64bit, ePO 4.6.6, singel Server
We use the ePO transfer mechanismen after sharing the communication keys vice versa.
The way mentioned in KB71078 could be one possible solution but I am not aware of how databases out of SQL Server 2005 32 bit are usable in SQL Server 2008 64bit. Due to a mentioned problem with EEPC (user assignement) we decided to build up a new Database in 2008 64bit.