Charles Wilt wrote:
On Thu, Aug 28, 2008 at 12:55 PM, CRPence wrote:
It is generally undesirable to try to effect a DLTUSRPRF and
RSTUSRPRF to /refresh/ a user profile on another system, not only
due to the amount of work it would entail, but those
system-specific and temporary details would be lost on the target
system.
Can you expand upon this as this is exactly what we are trying to do.
Can you think of other options besides a full DR type recovery?
Passwords alone aren't enough unfortunately, since not all the
profiles currently exists. Profiles are not automatically added to
the QA box when they get added to the Production box.
AFaIK the Management Central feature enables a synchronization of
user profiles from the central\managing system. This may be something
to look into, as possibly meeting the requirements to refresh profiles
to another system.
However as alluded, the SECDTA(*PWDGRP) is probably all that will be
necessary to satisfy most requirements to _refresh_ a profile on\to the
QA system; i.e. I believe that would be sufficiently usable for
unidirectional user profile synchronization, and quite possibly somewhat
acceptable in a bidirectional usage [if absolutely required, because
nuanced changes can be frustrating to users, which arise due to saves
and restores not being active synchronization]. Note: comments imply
the interactive profile entries (IPE) are restored in a restore-over, so
distinct custom system-specific information like *PRV settings would not
be available due to sav\rst sync overlaying settings from the source at
the target; I am not positive however, that is the effect.
IIRC all of the "fields" with the exception of *PWDGRP of each user
profile restored individually [or generically, but not *ALL], will be
restored from the save media in both scratch restore and restore-over
scenarios. And that the *PWDGRP merely increases the amount of "fields"
being restored, to include passwords and groups. Note: the doc calls
the various attributes of a user profile that are established by the
parameters from CRTUSRPRF & CHGUSRPRF as fields, for which I used
"fields" only to be consistent. The source of any doubt I have of the
completeness of the restore-over is for lack of explicit documentation
about restoring user profiles "individually" as compared to restoring
USRPRF(*ALL). The "all fields" is clearly stated in restoring *ALL, but
is never noted in restoring individually. For lack of using *ALL, the
onus is on the operator to effect any additional as-appropriate
synchronization actions, when outside of the full DR. DR is of course
the primary purpose of saving and restoring user profiles.
So although save and restore can be used to synchronize objects,
including user profile objects, the use of just save & restore may be
lacking to meet realistic synchronization requirements. Outside of the
sav\rst features some actions that may be required, are effecting proper
restore order and DLTUSRPRF, to reflect correction for an additive-only
effect of the restore; i.e. for which failing to do so might miss
expectations\requirements. This can be an issue for deleted objects,
members, and entries, changes that would or may not be reflected by a
simplistic sav\rst that is done in hopes of effecting even\only
unidirectional synchronization. Changed registrations, including
additions, would likely need to be done separately; e.g. ADDDIRE as
addendum to CRTUSRPRF, will not be synchronized by the sav\rst of just
the *USRPRF. The warning here... is to avoid assuming that restoring
the user profiles is accomplishing all of what is desirable and even
possibly required for the person associated with the QA profile to have
both a good and valid reflection of a production profile.
If the DLTUSRPRF is performed first on the target system, that is a
'scratch restore' of the user, so an effective identical copy of the
profile is effected on the target [using SECDTA(*PWDGRP)]; given group
profiles are restored before every member. The problems with deleting
first, are that all profile object ownership, registrations, and various
[effectively] temporary and system-specific features are be lost; e.g.
OBJOWNOPT(*DLT|*CHGOWN), directory entry, SQL sessions, user
preferences. Most obviously a problem, is that the ownership of all
objects at the target would be lost, requiring /correction/ after
restore of the user profile, and before RSTAUT. This seems such a huge
problem, that IMO, doing so would be undesirable in almost all but the
most extremely narrow cases of *USRPRF usage\existence; i.e. except when
the QA profiles are known and prevented from ever owning any objects,
such that any ownership is an indication of an obvious defect, that is
exposed simply by the existence of the owned or authorized objects.
Even so, re-registration scripts would need to be run after each
restore. There will be no recovery of other system-specific information
like *PRV resolution and SQL sessions, for example; the former because
the refreshed profile gets the IPE from the saved profile, and the
latter because there is no save/restore for SQL sessions... and maybe
others.
So basically, why DLTUSRPRF when probably using just the RSTUSRPRF
SECDTA(*PWDGRP) will suffice.? What more or better would come of doing
that? One advantage is that deleted profiles from the source system
would be reflected on the target. The great reason for a QA profile, is
that both ownership and authorities might inadvertently exist from some
prior test activity, and a full refresh of the user profile would
prevent that. But by doing RSTUSRPRF and RSTAUT might that not also be
an issue with authorities, in what improper authority might come from
the source system? Ideally and so atypically, any such issues should be
identified as part of the QA. However deleting the user profiles to
resolve such issues, might not be much better than ignoring those
issues. A better approach might be a scrub of ownership and authorities
that are beyond what the QA deems expected as possible and/or valid.
Regards, Chuck
midrange.com
