Porting A User Profile From One IBM i Machine To Another
July 23, 2014 Hey, Joe
|
We’re consolidating our IBM i partitions on another Power 7+ machine that belongs to my parent company. They want to move and install some special-purpose user profiles from of their partitions to one of our partitions. What’s the best way to port a user profile from one partition to another? –Tim You have two choices here. 1) You can either take a printout of the user profiles in question and manually recreate them on your target machine; or 2) You can back up and restore the user profiles from one machine to another. My preference is to back up and restore the user profiles from the source to the target machine because that will give you an exact duplicate of the original profiles along with any special authorities that apply to your box. If you manually copy the profiles, there’s always the chance you’ll make a mistake and the profiles won’t match. Here are the steps to follow for porting a user profile between partitions. Three Ways To Back Up Your Security Data To backup your user profiles from your source machine, you can either use the media from your latest full system backup, you can perform a Save System (SAVSYS) command, or you can perform a Save Security Data (SAVSECDTA) command. Here’s the rundown on how each of these backups save user profile data. A full system backup (GO SAVE, option 21) saves all your security data (including user profiles) along with the rest of the system. It requires a restricted system and it generally takes several hours to finish a backup. A System Save (SAVSYS) only saves your Licensed Internal Code (LIC), along with your security data. You can perform a SAVSYS on the source box by running GO SAVE, option 22. Like an option 21 save, it requires a restricted system. SAVSYS runs more quickly than an option 22 backup because it is only backing up your operating system and security data. A security data only backup (SAVSECDTA) saves all of your security data (including user profiles and authority lists). Unlike the option 21 and 22 saves, SAVSECDTA does not require a restricted system. You can save your user profiles anytime from your source system. This backup runs quickly. Here’s the command for running a SAVSECDTA save to save security data to a save file. SAVSECDTA DEV(*SAVF) SAVF(SAVEFILELB/SAVEFILENM) Restoring A User Profile To The Target Machine Once you have the security data saved, move the backup media to your target machine. If you saved your data to a save file (*SAVF), you can FTP the *SAVF to the target machine. Once the security data media is available, perform this Restore User Profile (RSTUSRPRF) command on the target machine. RSTUSRPRF DEV(devicename) USRPRF(user_profile_name) This will restore a user profile to the target. You can restore multiple user profiles from media or you can restore all user profiles that start with a generic wildcard (generic*). Restore Private Authorities To The User Profile After the profiles are restored, you’ll also want to restore any private authorities that are associated with that user profile. When you save a user profile with a full system save, a SAVSYS command, or a SAVSECDTA command, you also save all the object authorities that were associated with that user profile. To retrieve the object authorities associated with a restored user profile, run this Restore Authority (RSTAUT) command for each user profile that you restored. RSTAUT USRPRF(user_profile_name) Unlike the RSTUSRPRF command, RSTAUT will only restore authorities for one user at a time, meaning you’ll have to run one RSTAUT command for each profile you’re restoring. You can’t restore authorities for multiple user profiles or wildcard profile names. Also unlike RSTUSRPRF, you don’t have to specify the backup media or save file you restored the user profile from. The profiles are saved and restored with their private authorities intact. You just have to run RSTAUT to restore private profile authorities to the system. Don’t be worried if you see the following informational messages after you run RSTAUT. Some authorities not restored for user profile XXXXX. Not all user profiles had all authorities restored. This occurs if there were private authorities associated with the user profile on the source system that aren’t available on the target system (such as authority to a library that isn’t on the target). This is normal if the systems don’t match. RSTAUT will restore the authorities it can. Not Quite Finished Yet There’s one last step after restoring the user profile and its private authorities. Check all the parameters inside your restored user profile to see if the profile refers to any objects that aren’t present on your target system, such as job descriptions or message queues. Once identified, recreate or restore those objects on to the target to make sure your restored user profile will work correctly on the target system. And that’s all there is to restoring a user profile from one system to another. –Joe Joe Hertvik is an IBM i subject matter expert (SME) and the owner of Hertvik Business Services, a content strategy company that provides white papers, case studies, blogging, and social media services for B2B software companies. Joe also runs a data center and help desk for several companies. Joe has written the Admin Alert column for IT Jungle since 2002.
|
