The situatios is like this..
We have 2 EEM (Endpoint Encryption Manager)
This EEm was not setup by our team so we do not know the details on how it's was setup,
However after some incident of "get sync error unable to sync local database Error [e0050020]"
We relize that this setup is not Primary & Secondary istead only Primary and Backup..
So in other word it's not updating each other... EEM01 only updating EEM02. (backup to EEm02)
This error comes from package setting creation...
A package was configure and created to connect EEM01 & EEM02 whichever good connection.
- when machine installed and creating a profile to EEM02, this ok for sometimes until EEM01 updating/backup it's content to EEM02
- Profiles in EEM02 were deleted and replaced with infor from EEm01 (that why machine getting e0050020 error - it's profile was wipe during EEM01 to EEM02 backup processes)
We've identified this issue and new package built has been issue for all our sites to avoid getting this error..
Is there a way beside removing EEPC from client that having e0050020 error like export it SBFS info and then import it back to EEM so machine can continue connect and syn to EEM?
Is it possible?
Thanks in advance.
If the two eem are copies of each other, in theory you could simply export the machine from one and import into the other - whether it works depends on all the filemgroups etc being identical.
This is not a supported process though.
If we notice that there installation that was created on EEM02
We could import from EEM02 and export to EEM01 before data on EEM02 being update by theEEM01..
The problem we only notice that there are instalaltion that created on EEM02 and the data already gone after seen this error "get sync error unable to sync local database Error [e0050020]"
The SBFS is in good condition but since the profile which was created on EEM02 gone (after being updated by EEM01) so e0050020 generated..
The reason I ask this because if we could import key from SBFS we can save our time on removal processes because the SBFS is still in good condition..
I've highlight this to our site IT during installation to make sure that the client is creating it's profile to EEM01 and not EEM02.
Another question -
- can we configure some sort like alert that will notify us when new installation/machine name created..
- or is there mecanism to check for new EEPC installation.. like date created..etc?
If eem02 is a replica for disaster recovery, then you should NOT have a server active on it unless you are handing over to it - that's the best resolution for your problem.
I guess you can run reports on EEM02, but as above, the best thing is to simply turn the server off. You NEVER want machines creating or updating themselves in EEM02 when EEM01 is alive, and in fact, if you ever hand over to EEM02, then you should consider EEM01 dead and gone, and never use that DB again (start with a fresh replica of EEM02...)
Thanks Simon, Yes EEm01 seem to be configured for disaster recovery
Is there a way or guide to change it to act like primary & secondary and update each other if there new installation created in either one of it database?
because there could be more machine will be encrypted I believe we need to utilized both server for our worldwide user..
no. bi-directional sync is not supported. You need to ensure absolutely that only one DB is live at any one time, and if you switch over, the new one becomes the master from that point on.
Ok got it.. Is there a way to point the installation of database registration to only specific server?
when we created installation packages there option to update to server list eem01 & eem02 - last good connection etc..
but there no statement that client need to contact to only specific server for registration..
could be some setting in file?
you need the clients to know about both servers - otherwise your DR plan doesnt work. If you only want the client to ever talk to one server, then just don't select it when you create the install set.
It's all in scm.ini - but it's not really a supported procedure to change that on the client.
I think you need to go through the "Hot Backup" documentation again, and match that against your requirements, or talk to the team who set it up to understand what they were trying to achieve?