When windows introduced User Access Controls (UAC) years ago, I knew we were in trouble.  These controls have caused me more troubles as an administrator of systems then any other windows feature that I can think of and there are lots of features that drive me crazy.  I recently had a client change their group policies up which tightened things up and for their organization it is a huge positive, but for a backend administrator that just wants to get the crazy installs and configurations done the policy change impacted my administrator account very negatively.

According to my privileges I had UAC turned off, I was in the administrators group, I was assigned the administrator privileges but I was still unable to delete a file from my temp directory without it tell me that “You’ll need to provide administrator permission to do <this action>”!  Seriously, I created the file, I modified the file, I am the owner of the file, but sorry today, you can’t delete it!  Come on man!  Really!

Now I understand the reason why, and if you don’t understand why, do a little reading on UAC, and if you still don’t understand, I highly don’t recommend you make this change I am about to suggest.

The policy forced a registry setting that I could not change any other way then through the registry editor, and once I changed a rebooted the machine, no more problems:

Key: Software\Microsoft\Windows\CurrentVersion\Policies\System – Value: EnableLUA

This was set to 1 (Hex: 0x00000001) which enables the policy “administrator in Admin Approval Mode” user type while also enabling all other UAC policies. I changed the value to 0 (Hex: 0x00000000) which disables the “administrator in Admin Approval Mode” user type.

After a quick reboot, I was able to delete my files from my temp folder without having to grant administrator privileges to the action.  For more info on this registry key check out Microsoft MSDN!

When working on a new server, I have encountered this error a couple of times.

UBBGEN.exe is missing the mfc100u.dll. This is because it can’t find it in the system32 folder. In order to fix it you need to run the Visual Studio Retail Assemblies in the server.

In 8.51, go to the %PS_HOME%\setup\vcredist\ run the 64 bit executable. If it prompts you select to repair, otherwise just follow the prompts.

In 8.53, go to the %PS_HOME\setup\psvccrt\ run the program psvccrt_retail_x64.msi.

Restart your psadmin session and you should now be able to build your application server and process scheduler domains without an issue.

During Upgrades of the Toolset and various maintenance, I have ran into issues with the SYSAUDIT showing IBRK-13 issues.

This is caused by the Service Operation Table missing entries. PeopleSoft has a little workaround that nicely solves the problem:

/** Step 1: Verify Data: Store/backup data***/
select * from PSSERVICEOPR order by 1;

/*** Step 2: Delete data ***/
delete from PSSERVICEOPR;

/*** Step 3: Verify Delete ***/
select * from PSSERVICEOPR order by 1;

/*** Step 4: Insert data ***/
insert into PSSERVICEOPR (
select A.IB_SERVICENAME, B.IB_OPERATIONNAME
from PSSERVICE A, PSOPERATION B
where A.IB_SERVICENAME=B.IB_SERVICENAME);

/*** Step 5: Verify Insert ***/
select * from PSSERVICEOPR order by 1;

I was working with a client recently and they wanted some help setting up change assistant in order to apply some bundles to their environment. Seems like a pretty straight forward request. While doing a WebEx session we installed the change assistant and setup the agents and download the patches/bundles and then went into the change assistant to apply them. This is where things went weird.

After going through all the prompts to apply the change packages, the second last prompt is to enter the userid/password and accessid/password. Once the password was entered and the next button clicked, I received a Java Platform Platform SE Binary has stopped working. When you clicked on more details it shows that javaw.exe has crashed with a bunch of weird codes.

The versions I was seeing in the error code, made me think that there was some issue with the Java, so I made sure I was using the current version of java. Still no dice. So I tried a newer toolset, and went through the process to upgrade to the latest toolset. Still no dice.

This is when it dawned on me. I had the system administrator entering the accessid password during the remote session, and when I actually saw the password, it was 9 digits in length. I changed the password to an 8 digit password and we were in business.

This is an actual note from PeopleSoft: IMPORTANT NOTE: One thing to remember is that PeopleSoft does not support an Access ID or Access ID password of over 8 Characters. It MUST also start with an alpha character and can not contain any white space, or any of the following characters: ; : & , < > \ / ” ‘ [ ] { } ( )! % * ? – = +

The @ $ # characters will sometimes work, depending on DB platform, but cannot be at the beginning of the password. The Access ID cannot be a restricted word used in the Database either.

So there you go! There is an enhancement request to make the sysadm password handle larger sized passwords but I believe this case 1076084.1 has been open for a considerable time. I can remember being a DBA at one site almost 10 years ago, and they insisted that all administrative password had to be 16 digits. After a long and intense battle all passwords were changed to 16 digits except the accessid password.

I was recently trying to test a system for a client that was trying to do some year end testing. In order to do this testing in the past they use to simply use the Oracle Database function “FIXED_DATE” to future date their database. When you use the FIXED_DATE feature it effects the SYSDATE variable and returns a date that is not the date of the operating system.

Unfortunately, with the more current releases of PeopleSoft, they have changed several of their system calls from SYSDATE to SYSTIMESTAMP. For some reason SYSTIMESTAMP is NOT effected by the FIXED_DATE override parameter, and from everything I have read there is no override parameter for changing the SYSTIMESTAMP. This leads to the problem of how to make future date testing work within PeopleSoft.

The only real solution is to future date the operating system. However, there are some real concerns that can come with this idea. I personally would highly recommend that you clone the server you are working on and use the cloned machine for this future date testing.

My testing system is stored on RackSpace servers, and when I made the cloned server and tried to change the OS date, it said it changed it, but when you looked again, it was still the current date/time. It turned out that the RackSpace system uses XEN on the RHEL OS to keep the server times in sync. I found the best way to change this was to add the sysctl parameter:

xen/independent_wallclock = 1

Once, I rebooted the server, I had no issue controlling the OS clock.