Undeployment situations

The following situations occur in these specified undeployment scenarios:

• After undeploying a WinPlatform, only the Bootstrap software remains on the target computer. All other WinPlatforms are notified of the undeployment of the WinPlatform and stop trying to communicate with it over the network.

• Alarm Clients know immediately that an area is undeployed and is no longer available. They remove the area from selection lists. Alarms associated directly with the area (not as a result of containment) are immediately removed from current alarm views.

• Undeploying an object that has Pending Updates status removes that status. It is now marked as undeployed.

• If cascade undeploy fails on one object, then the undeploy continues to the extent possible on other objects. The entire operation is not terminated because the undeploy fails for one object. However, you will not be able to undeploy a container object if one or more of the objects assigned to it cannot be undeployed (for example, if an object is open in the Object Editor).

• Redundant AppEngines: Assume an ApplicationObject is hosted by the Active AppEngine in a redundant pair and a number of subscriptions is configured in that ApplicationObject that refers to items in a DIObject. If you undeploy the ApplicationObject in question, the items are not removed immediately from the item count of the DIObject. How fast those items are removed depends upon the value of the Maximum time to maintain good quality after failure option (Redundancy.StandbyActivateTimeout attribute) on the Redundancy page in the AppEngine’s editor. This behavior does not apply to the undeployment of ApplicationObjects hosted by non-redundant AppEngines. For more information, see Working with AppEngine Redundancy.