Problem with moving enterprise global (migration to another sever)

[richecity]

Does anyone know of a process or a utility that is available that allows for
the Enterprise global file from one server to be moved to another server
without causing conflicts(i.e. calendar issues). We currently have several
servers that we use to develop (development server), test (test server), and
deploy(production sever) all new modifications and changes to MSP Pro. I have
asked a related question before, but the response I got was to use organizer
to copy over all enterprise elements to a project plan (.mpp file), and then
use that plan to facilitate moving the objects from the source server to the
target server. This is a interesting, but mediocre solution because (1) it
is etremely manual and time consuming and (2) Enterprise Fields cannot be
copied to a project plan, which means they have to be mapped to local fields
in order to be copied to the plan and then mapped to from the local fields to
enterprise fields on the target server (WE have alot of custom enterprise
fields and to do this for each one is extremely manual and time consuming and
cannot serve as a migration procedure in a corporate environment where
customers utilize MSP Pro daily). I need for an alternate and efficient way
(if such thing exists) for the changes made to the one server's global to be
"migrated" to the another server (including enterprise fields). Also the
resource pool must not be altered on the target server, so simply restoring
the SQL DB will not work. This puzzles me because it seems as if Microsoft
didn't even consider this when they developed MSP Pro. It is an "enterprise
tool" but they didn't consider the way "enterprise" apps are develeoped,
tested and deployed. Any info that you guys might have will be greatly
appreciated.

Thanks

Riche

 

[Gary L. Chefetz [MVP]]

Reid:

How often do you do that?

 

[Reid McTaggart]

A few times per year. I sometimes take clients' EGs and restore them to my
image, usually to diagnose problematic custom fields, filters, or views.

So, I may have been blissfully unaware of calendar or other issues.

Are there some gotchas I should know about? Thanks!
--
Reid McTaggart
Alegient, Inc., Houston
Project Server Experts
Microsoft Certified Partner

 

[TGG]

Reid,

The issue we ran into was duplicate views, duplicate calendars, duplicate
forms and other duplicate messages when you opened the project. The users
would then flood us with support calls.

We also started off on 2002 and migrated to 2003. Those who started on 2003
*might* not see this behavior

Also, if you made changes to enterprise fields, they wouldn't necessarily
update the local client and you would have value errors. The only resolution
was to clear all local content(fields, views, etc) in the organizer and let
the enterprise global repopulate the local settings. Having to do this
across all project managers was a nightmare. Also, having to do this
everytime a change was made made it a really painful experience.

In discussions with the Project product team, I have brought up the need for
a environment configuration management tool for Project 12 since we have dev,
test, prod and training environments to keep synchronized. Currently, we are
using an all manual process to maintain consistency.

This is the first I've heard of the MPP file method of moving configuration.
Very interesting and sounds like someone could get very enterprising coding
up a macro to automate the process.

TGG

 

[richecity]

TGG

Yea those are the same issues we ran into, however, we started out with MSP
2003.

 

[Reid McTaggart]

I've just had any user with such a problem delete all instances of the file
GLOBAL.MPT from their machine. One of my more sophisticated clients created
a little "push install" type program to do this for users when they boot up.

I'm very interested to know if I'm missing something important by using this
approach. I learned it from some smart people... but nobody knows everything!

I will say also that most of my clients get their production configurations
pretty well developed before initial rollout. Then, changes they model on
their test and staging instances are fairly incremental. Usually, rolling
such changes to production is accomplished via a documented change process
wherein they modify the production EGlobal (and PWA) instead of replacing it.

Thanks!

 

[Gary L. Chefetz [MVP]]

Reid:

I've never had much trouble with entire databases, but sometimes a EG
restore can cause havoc.