Server migration causing calendar issue

[richecity]

Hello all,

I have an interesting problem that is occuring when migrating to a different
server. We currently have 3 servers: development, acceptance test (AT), and
production. We migrate from development to AT and test all changes on AT;
finally, once everything has been tested we migrate from AT to production.
Recently we noticed that during migration, new calendars we being created on
the server we were migrating to. For example, if the development server had
2 calendars in its enterprise global, Standard and Acct Calendar, and prior
to migration, AT had the same two calendars, for some reason after the
migration AT would now have Standard and Acct Calendar1 (not Acct Calendar).
Also, on AT server all resources were assigned to Acct Calnedar prior to
migration, but after, they are now all assigned to the Standard Calendar. If
I open the organizer, the regular Acct Calendar has been deleted. We have
tried this several times and the same results occur. However, if we perform
the migration from development to AT with development having both calendars
and AT having only the Standard Calendar, the Acct Calendar shows up fine in
AT after the migration. Only problem with this is the resources that are on
AT need to have the Acct Calendar as their base caendar, so this poses a
problem since everytime we save it their it gets deleted. Any information on
this occurrence will be greatly appreciated.

Thanks

richecity

 

[Gary L. Chefetz [MVP]]

Rich:

Before I could begin to take a stab at this, I'd have to know the exact
procedure that you're executing under the term, "migration."

 

[richecity]

When we migrate to another server we simply run "Restore Enterprise Global"
under Tools > Enterprise Options from the server we are migrating to. This
is how we "migrate" the latest changes to from one server to the next.

 

[Gary L. Chefetz [MVP]]

I don't trust that procedure. Restoring one system global to another system,
in my experience, can cause calendar conflict problems. Instead, replicate
changes to the Global file by moving them into a project plan. Save the plan
as an mpp and use it as a source to move the changes to the other system.

 

[richecity]

When you say move the changes into a project plan, will this save custom code
changes and other customizations as well (i.e. bar styles, enterprise
fields, etc...) as well? Also, when you mention "move the changes to the
other system", will I still have to use the restore feature to get them onto
the new server. Thanks for your help, I have used much of your advice on
other posts and really appreciate your knowledge.

richecity

 

[Gary L. Chefetz [MVP]]

Rich

You copy, you don't restore. You can copy views, filters, etc. into a
project plan. You can import values from Enterprise fields to local fields
and back again, allowing you to use a project plan as a conduit for moving
them from system to system.

 

[richecity]

Interesting approach. So I would utilize the organizer in order to move the
views, filters, etc.. from the mpp to "checked out enterprise global" on the
server I want to migrate to correct? When you stated "import values from
enterprise fields to local fields" are you also referring to using the
organizer also or some sort of seperate mapping? Thanks for the technique
Gary, I believe you just saved me from more headaches!

 

[Gary L. Chefetz [MVP]]

Rich:

Sounds like you got it, but you don't need to open the Enterprise Global to
do this. Doing so, in fact, opens your global file up for corruption. The
copy and move approach is a little more work, but completely avoids global
file corruption on either system.

 

[richecity]

Ok, but my understanding was that you have to open the enterprise global file
in order to place all enterprise objects that you wanted in your
organization's "library" for all projects to use. If I simply open up one
project and copy over the elements to the global (+/- cached/noncached) list,
this will not actually save the copied elements into the global file correct?
I want these new enterprise objects that was saved in the mpp file to be
copied to the new sever and be available to all projects that will be created.

 

[Gary L. Chefetz [MVP]]

Rich:

I said that you don't have to open the global on the source machine.

 

[richecity]

Thanks Gary!

Rich:

I said that you don't have to open the global on the source machine.

 

[richecity]

Gary,

For some reason when I open up the .mpp filed used to copy over enterprise
objects, a few enterprise date fields will not show up on the target server
when I open organizer. The weird thing about this is the new enterprise
fields dont show up in the .mpp file's list box in organizer. It seems as if
MSP ignores any enterprise field that doesnt exist in the global, even if the
field is "local" to the project plan used to copy over the new elements.
Have you ever encounted anything like this?

Thanks

 

[Gary L. Chefetz [MVP]]

Rich:

Your question has me confused. No field, that doesn't exist in the
Enterprise Global, can be considered an "Enterprise Field." With that in
mind, try to clarify.

 

[richecity]

Gary,

Sorry about the wording. What is hapenning is when I am on the source
server in organizer, and copy an enterprise field over from the global list
to the an the .mpp project plan's list (lets call this file transfer.mpp),
it copies fine. When I then close and reopen project, connecting to the
target server that I want to move the fields to, open transfer.mpp, and then
open the organizer within the checked the enterprise global, the fields that
I just copied to transfer.mpp from the source server don't appear in the
transfer.mpp list (so I cannot copy them to the global file). However, when
I close and open the transfer.mpp file on the source server and view its
contents within the organizer there, the fields appear. IT almost appears as
if MSP is blocking the fields from being viewed somehow.

 

[Gary L. Chefetz [MVP]]

Rich:

You can't copy enterprise fields to a project plan. You CAN copy the field
values into non-enterprise fields. What you want to do is setup a plan that
contains local fields and outline codes that mirror the enterprise fields
and codes and use these to move the values from text fields with value lists
and outline code values to the new system.

 

[richecity]

Thats it! Gary I really appreciate your help through this issue. Thanks alot.