× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.