Any known issues upgrading from DFM 3.5.x to 3.7.1

[emanuel]

Hello everyone

I am helping a customer debug a recent upgrade to a new server ... all objects have come through but a few user created groups are missing ( say about 95% of groups made it ) or not all of the qtrees in a group made it.

The upgrade was a stand in place ( upgrade to 3.7.1 on the old server ), create a backup copy, then copy the database to the new server.

This upgrade was performed about three weeks ago.

We are going to be using command line dfm group commands to list the old server group info and manually re-add them.  By creating new groups in the new server, the group id will change and can effect anything that may be hardcoded to the group number.

[jmc]

The objects may fall out of groups if the whole storage system is manually deleted, or the objects themselves seem to disappear (SNMP doesn't report them), or they were manually deleted. When they are re-added (either manually or automatically when the monitor sees them again after some SNMP issue), they will not be put back into the groups they were originally in.

I would check the "audit.log" and see if anyone really deleted the groups.

Also check "dfmmonitor.log" (and rotated copies) for messages about the monitor deleting/adding them (look for the storage system name, if the whole system disappeared).

Note that OM/DFM won't immediately delete anything that disappears, and the FAQ tells you how long it waits, so short disappearances usually don't cause any issue like this.

Cheers,

Jonathan

[emanuel]

What is interesting is on the new server, the qtree counts on the groups have changed ... some of the groups after the database move have inheritied more qtrees.  We have to investigate if those extra qtrees are the ones missing from the other groups.

We just finished adding the missing qtrees in their respective projects.

I will find out if there is time to comb through the database to look for evidence of device removals

[jmc]

If it was from a much earlier DFM version it might have been explained by the way we changed reports membership when we added hierarchical groups to the product, but that's a long time ago (DFM 3.2). Certainly I don't know of anything since 3.5 that would have done it as part of an actual upgrade of the database.

If you have the 3.5 database, load it onto a test machine running 3.7.1 keeping all services except sql shut down during and after the "dfm backup restore", then run a report at the CLI for a group you think got changed (and run same report on the 3.5 server to compare).

Cheers,

Jonathan