While ‘resting between engagements’, I took the opportunity to install and configure a Solution Manager system on a cloud host local to Australia.  The main reason was for a demojam entry, but it’s always good to keep my skills up to date.  The target system provided was a Windows 2008 R2 system.

Windows
Server 2003 R2 and Windows Server 2003 only have functional differences; using the same SAP kernel version, the same service packs, and
the same hot fixes and security fixes.  By contrast, going from Windows Server 2008 to Windows Server 2008 R2 requires an updated kernel (see SAP note 1383873 – Windows Server 2008 R2 Support).  Now, I could say I was using 2008 R2 for all the right reasons; for example, according to Frequently Asked Questions – SAP on Windows Server 2008 R2:

The main benefits of Windows 2008 R2 are

• Scalability
  Windows Server 2008 R2 supports up to 256 logical processors.
• Improved virtualization features
  On Hyper-V in Windows Server
  2008 R2, the amount of cores supported by the hypervisor (up to 32) has
  been enhanced. Another enhancement is Live Migration support by the
  implementation of Cluster Shared Volumes (CSV). Virtual Machines can be
  migrated without service interruption between the cluster members.
• Power usage
  Windows Server 2008 R2 reduces processor power
  consumption in server computers with multi-core processors using a
  feature known as Core Parking. Core Parking allows Windows Server 2008
  R2 to consolidate processing onto the minimum number of required
  processor cores, and suspends inactive processor cores. The advantage of
  Core Parking over traditional servers is 10-15 % energy saving for the
  same workload.

For a complete list of features, see:
http://www.microsoft.com/windowsserver2008/en/us/overview.aspx

However the real reason was that Windows 2008 R2 was already installed on the server I was using.  This became a bit of an challenge, as the Install Kit I used wasn’t actually for 2008 R2 !!.  I found OSS Note 1383873 fairly quickly, but even after installing the appropriate kernel as suggested,  sapstartsrv.exe (used by the SAPxxx_NN service) would not start correctly.  I discovered via google that I needed to install an extra Microsoft c-runtime (vcredist) to run the new SAP kernel.

The reason for posting this as a blog (I’ll also add it to the wiki) is that while I’ve since found out that this is ‘general knowledge’, it wasn’t described in OSS Nnote 1383873 – Windows Server 2008 R2 Support , and in fact, the only reference I found to my symptom was in one line in 1494740- SAP system migration from Windows 2003 to 2008 (R2) 64-bit AFTER I chased the error down through Google.

Are you implementing or using Windows 2008 R2 ? If not, why not ? Corporate standards ?, Lack of product support ? Lack of in-house knowledge ?

Sales are tanking, money is tight, the company is cutting costs everywhere. And you want them to fund your SAP upgrade project ? Given that only about one-third of SAP customers have upgraded to ECC/ERP 6.0, and most of these have opted to do only technical upgrades in order to save time and money, you’re not alone.

The challenge you have is that there’s no business payback for doing a technical upgrade – the only thing you end up doing is staying on support. Going to the board with this as your major justification will get your submission (and maybe you !!) thrown out.

This means you need to be creative in seeking out the payback. Not even the pure techos like to use staying on support as the main justification for an upgrade. So you need other business drivers for SAP upgrades, including the benefits of new business and technical functionality and creating a foundation for other business initiatives.

However, there are some support-driven reasons to upgrade that could pay off. One of the drivers is mitigating the risk of receiving slower maintenance responses from SAP.

Also, with a technical upgrade, you can leverage your existing existing resources to enable the upgrade, such as using the opportunity to replace hardware. For instance, switching to Windows operating system from Unix may substantially lower costs, or alternatively, changing application servers to energy (i.e. cost) saving Linux blade-type servers.

Using tools like those provided by HCL, Intellicorp or Panaya can give insight into how the current, live production system and older systems are being used. This will also identify how end users are using the system, by looking at how the standard and customized parts of the system are being used. This raises the possibility of removing some of those customized areas, and containing costs by focusing testing and support on the modules and components being used.

But the biggest driver for an upgrade is another factor (and perhaps one more reason to complete the SAP technical ERP upgrade): not having to do any more of them.

Being on the NetWeaver platform and ERP 6.0 will allow companies to adopt SAP enhancement packages . These are a mature (first released in 2006) method of applying new functionality to individula modules, and, eventually, updates to the core platform. SAP has said many times this means the end of the traditional upgrade.

Occassionally, when loading Support Packages or SPAM/SAINT Updates, the Support Package Manager (transaction SPAM) can get a bit ‘confused’. A colleaugue had this problem recently, where she was attempting to update the SPAM tool on a 4.6C system. The result was that the Support Package Manager was reporting Queue_Not_Empty .

Some times the cause is simply forgetting to confirm / finish the last SPAM/SAINT update. Once you’ve eliminated this, you need to start checking what the TMS mechanism thinks has happened. To check what is in the TMS buffers, logon to the Operating System, change directories to /usr/sap/trans/bin and execute the following:

tp SHOWBUFFER -D SOURCESYSTEMS= TAG=SPAM


Basically you need to reset the SPAM Queue to match the TMS buffers. To remove entries from the internal SPAM Queue, uUse the function module (transaction SE37) OCS_RESET_QUEUE. Execute it with parameters IV_TOOL=SPAM, IV_FORCE=X. To remove entries from the TMS buffer, execute the following command (change directory to /usr/sap/trans/bin first), where SAPKXXXXX is the 'offending' Support package or SPAM/SAINT Update:

tp delfrombuffer SAPKXXXXX pf=/usr/sap/trans/bin/TP_DOMAIN_.PFL