The transition to NetApp MS Azure AD B2C is complete. If you missed the pre-registration, you will be invited to register at next log in.Please note that access to your NetApp data may take up to 1 hour.To learn more, read the FAQ and watch the video.Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.
Last weekend started an update of OnCommand Unified Manager (OCUM) ver.5.1 to 5.2 - which is running on a VMware Virtual Machine.
Before starting the OCUM update, I created a VMware Snapshot for safety sake.
OCUM update 5.1 to 5.2 went well, but problems started when I had to update the OnCommand Host Package v.1.2 to v.1.3.
Host Package update failed with errors, so tried to uninstall Host Package v.1.2 manually; when running this procedure, the uninstall process took ages and finally failed.
It took a couple of days to find the solution to this uninstall issue, but finally I am running OCUM 5.2 with Host Package 1.3.
When starting the OCUM GUI, I can see my VMware VM backups and VMware datastores, but the displayed objects are not selectable for restore; so I am afraid that something got lost during my Host Package issues.
My question is as follows:
If I restore my OCUM VM to a snapshot state of 5 days ago (where system is running OCUM ver.5.1 again), all backups which have run after the update, will be lost offcourse. But will OCUM pick up all scheduled backup policies again and run all backups again (of course with a gap of a couple of days)?
What happens with the netapp snapshots, which were made in the last couple of days? Can/should I delete them manually?
hi Udo, sorry for late response - it's been quite a while since I visited the community.
So here is what I did.
The situation is arising from the new Remote Desktop Session Host introduced with Windows Server 2008 R2. Apparently, the Remote Desktop Session Host allows multiple installs to be in process at the same time by queuing the installs. It is my guess the process that queues the installs is the "Windows Installer Coordinator".
I discovered this Windows Installer queuing behavior is controlled by a System Group Policy called "Windows Installer RDS Compatibility".
When the Remote Desktop Session Host is enabled, by default, the Group Policy for the "Windows Installer RDS Compatibility" is enabled. When I disabled "Windows Installer RDS Compatibility", the chained MSI was able to run.
To disable this group policy: 1) Log on to the system with a User that has Adminstrative Privileges 2) Open the Windows Control Panel 3) Perform a search for Group Policy 4) The search results should display a link to the "Local Group Policy Editor" 5) Once inside the editor, go to: Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Application Compatibility 6) In the right pane, right click on 'Turn off Windows Installer RDS Compatibility" and select Edit from the drop down menu 7) Select the Radio Button labeled 'Enable' 😎 Click OK Unqt So now I was able to uninstall the v.1.2 Host Package successfully.