I got a notice today that my service provider needed to reboot my servers as there was a vulnerability that was exposed on the actual host that could cause problems and the only way to fix it was to reboot the entire host.  So I wanted to ensure that everybody was off the system and cleanly so that there was no  problems because this is rare that my entire server set would be going down at the same time.

On my windows machines I wanted to make sure that nobody was still connected via remote desktop connections.  To do this quickly, from a command prompt I issued the command:

qwinsta

Another option would be to use the SysInternals Suite of Tools which is available from Microsoft, there is one called PSLoggedOn that will give the information you are looking for.

On my RedHat 6.5 servers you can issue the command:

who -a

There is another one called “w”  that will give similar information but for a quick look the who command works great.

During the last upgrade pass I was attempting to apply patches to the upgraded environment and ran into an unusual error when trying to build the change package within Change Assistant.

As it turns out when we build the image, we did not force it to always use the same IP address.  So every time it starts the IP address has a tendency to change.  As it turns out this can cause some problems with the configuration that was done before on previous passes.  Depending on your setup you may find that the Oracle Database Listening will not work, which in turn makes it unavailable for the application server and process scheduler and the database is not listening to requests.  So you will need to change the listening and tnsnames files, as well as the tnsnames file on the server where change assistant is running.

However, the error with building the change packages was caused because the mapped drive for the “pi_home” on the virtual image was mapped as a network drive using the IP address.  Once the mapping was changed and the pi_home was available the change package error was eliminated.

As part of my post go-live procedures I was trying to do some comparisons from the pre-upgrade environment to the actual production environment.  Usually this is very straight forward and can be done using the Linked Server.  As it turned out the linked server was already configured however when I tried to do the sql lookup on the PSOPRDEFN table I got an error.

Msg 7411, Level 16, State 1, Line 1

Server ‘mvDBSERVER? is not configured for RPC

To re-enable the RCP commands for the linked server you can do it in the options GUI or from the query window:

exec sp_serveroption @server=’myDBSERVER?, @optname=’rpc’, @optvalue=’true’

exec sp_serveroption @server=’myDBSERVER?, @optname=’rpc out’, @optvalue=’true’

Now when I run [myDBSERVER].[PREUPGDB].[dbo].[PSOPRDEFN] I get the results I am looking for!

Okay, this is a little embarrassing but it points out an important concept.  Sometimes reviewing the basics can save you a lot of time and frustration.

During my last go-live weekend we cut over to a whole new infrastructure for the new HCM 9.2 environment.  This included an external web server for the e-recruiting module that is in use.  The new web server was configured and up and running and the SSL certificates were in place and for testing purposes I put an entry in the hosts file to verify everything worked.  On go-live we had to change the external DNS and NATs for the new servers so that it could work in the DMZ.  According to the network guys everything was done and the only thing they could tell me was that my Weblogic Web Server was not running or not accepting requests.

Now clearly, I was on the actual server and had tested everything so, I know that the Weblogic was working and it was communicating to the application servers.  I could RDC to the server and even map UNC paths to the other servers to get files to and from the old servers.  Clearly communications were working.  It just simply wouldn’t allow http and https traffic.

Turns out that this server was created from a completely different VM template than all my other servers.  When I looked closely I found that the Windows Firewall was turned on and was blocking the web traffic.   Unfortunately this was after about 5 hours of having the network guys looking into the problem.  Now they had to do some work but the problem clearly could have been resolved VERY quickly if I had just thought to look at the settings on the server.  Oh Windows Firewall how you frustrate me.

I have a little test site setup for Oracle PeopleSoft and I ran into an issue the other day where my sysadm account was expired. I typically have never ran across Oracle Database expiring my administrative user accounts. A little google search later and I found Amit Rath’s blog on fixing this problem.  It turned out that I had a default profile that had a time limit of 180 days for the password.

SQL> select profile from dba_users;

All of my system administrative users had the profile:  DEFAULT

SQL> select * from dba_profiles where profile=’DEFAULT’ and RESOURCE_NAME=’PASSWORD_LIFE_TIME’;