David Hallberg

Preparing for Your 2012 Upgrade, Part 2

Today, in the second half of my recommendations for ensuring a smooth transition to Millennium version 2012.x, I’ll look at Windows and Cerner’s back-end application nodes. (To see my thoughts on Shared Service Proxy settings and WebSphere MQ, see Part 1.) I recommend you check your settings in the following areas of your 2012.x domain:

  • Microsoft added the User Account Control to Windows to protect computers from running unwanted programs, but this feature can cause unwanted interruptions in running Millennium applications. If you are using Windows Server 2008 SP1 32-bit or Windows Server 2008 R2 with Virtual Machines (VMs) running Windows Server 2003 R2 SP2 or Server 2008 SP1 32-bit, make sure the User Account Control is disabled. Two documents explain how: “Turn User Account Control On or Off” from Windows and “User Account Control Step-by-Step Guide” from Microsoft TechNet.
  • DNS devolution includes improved security in Windows Server 2008, Vista and Windows 7. Make sure you have it set. Documents to explain how are on uCern at “Windows Vista Minimal Configuration Guide, Install Windows 2008” or “Microsoft Windows 7 and Windows Vista Configuration.” Microsoft offers “Post Installation Behavior … after you install the DNSA update.”
  • In the past six months, I have run across more and more sites that have incorrect settings for permissions and owners of files and directories. You can correct the settings by running the secure_cerner_500 executable located in the $cer_exe filesystem. Run it as root, and provide the correct inputs. One caution about this executable: If you are running more than one domain on the same server, lpar, npar or vpar, you have to remove the sticky bit on the files in $cer_fifo, $cer_lock and $cer_usock. If you only have one domain per server, lpar, npar or vpar, this will not be an issue.
  • Defrag the $cer_config filesystem to improve throughput for the security and transaction database servers.
  • Use the bcheck tool to rebuild the dic.idx file on each application node. If bcheck is not in your $cer_exe filesystem, look in $cer_ocd and find the file named bcheck.dat. Rename the file to bcheck, and put it in $cer_exe. You can search uCern or log a Service Request to get Cerner’s recommended flags to use on this. You might also be able to use the -? flag to get a list of the switches that can be used when you create the file.
  • Finally, you want to check the dedicated Shared Service Proxies (SSPs) for your security servers to make sure they won’t be overloaded with connections. At a minimum, you need an SSP for each instance of the Security Slave processes. If you want to have the Security Master service on its own SSP, add one more instance than is needed for the Security Slaves. This means you will have an SSP on the application nodes with no connections, but that’s okay. The SSP only takes 3MB of memory. If you have 2 Security Slaves running with your Security Master and 3 Security Slaves on your other application nodes, you will probably have to increase to at least 5 Security Slaves running with the Security Master and 6 Security Slaves everywhere else. This means you’ll need at least 6 dedicated SSPs for the Security Slaves; if you want a dedicated SSP for the Security Master service, you’ll need 7 dedicated SSPs. Remember to start the dedicated SSPs prior to starting additional Security Slaves in order to get the desired load balancing. Your goal is to keep the maximum connections for each Security Slave under 300. You can check the maximum connections from the Server Control Panel. If you want the steps for how to do it, send me a comment, and I’ll send them to you.

Prognosis: If you prepare for conversion by looking at and correcting your infrastructure and key items in your 2012.x domain, you will have a much quieter upgrade.