Invalid Planning Version

Now, I've seen a few errors on the SCM systems in my time. But this one really took me around a lot of corners.
It all started with a simple homogenous system copy. We were changing provider, and had to move our systems. After the migration, I did a few spot checks on the Live Cache, was it running, etc. And those simple checks were ok. But when we handed over the system to business, a simple forecasting ended my world. It started with a "livecache not accessible" error. This lead to a slew of missing parameters, missing configuration items, and authorization issues on the host. However, after several days of back-and-forth, the provider finally said "now it's working". So we tested again. Yes, live cache was now available, but the forecasting now gave an "invalid planning version". WTF ?!?

Clicking the error just took me to the S000 menu. So not much was offered in the way of help from SAP.
However, I COULD go to transaction /SAPAPO/MVM, and the planning version this time at least gave me an error:

An application error has occurred in the LiveCache

Message no. /SAPAPO/MVM075

Ok. I had something to go on... I tried to run a consistency check in /SAPAPO/OM17. And I do mean tried. It failed horribly too. Shortdump. What was that about ? So I ran the consistency check without selecting any object to test, and lo and behold, I caught a fish. 

Right, the planning versions. Here they were, plain as day. Clearing inconsistencies, quickly removed the entry not in the database. But why wouldn't the planning version load from the database ? All my checks on the Livecache said it was running ! Various SAP notes suggested restarting. I tried. No help. I even found a note that said to recreate the object manually (note 2419054), if the clearing didn't make the error go away. But I had no clue about how many objects were impacted, as I couldn't run the consistency check in its entirety. It could be a LOT of objects that required manual intervention, so I dismissed that idea for the time being. It had to be something closer to home. I needed to find the cause of the problem, not fix the symptoms.
I finally went back to LC10, and went into the monitoring. Everything looked ok, but something was fishy, it had to be. Something in the back of my head told me to check the datafiles. they were there. so I checked the tables within... And ... CRAP. They were empty.

So no wonder the livecache couldn't write to the database, or read from it. No wonder I got a shotdump when trying to read the data tables. There was just a clean database, with no imported tables. Not a single APO entry in sight. So I had my culprit. Now I just have to find out how the provider could have mucked up the restore. Not to mention, having them restore everything again.

Installing SAP content server on a windows 2012 with IIS 8.5

As I may have said once or twice before. SAP is "old" technology, and things built on legacy technology doesnt always hold up to modern times. A prime example is the Content Server, which certainly works on Windows 2012, and with IIS 8.5 You just can't install it with the installer (!!!)

Now, the problem isn't bigger than you have to do the installation manually (like we did before the installer tried to do everything for us). The major issue is that SAP has removed those installation guides, because the technology is no longer supported (Someone go smack the guy who decided to remove good, working knowledge from a knowledge database). So what you do is follow these simple steps (you may have to change the paths, depending on where you installed):

1. Install with the installer, as you normally would. Everything will look fine. But there will be no websites installed, even though you clicked the "install website".

2. Go to Internet Information Services Manager 

3. Right Click on Sites > "Add Website" to create a new Website.
- Site name  "SAP Content Server"
- port "1090"
- Physical Path "d:\sap\ContentServer"
- Application Pool > Select "DefaultAppPool"
- Click "OK"

4. Right click on the newly created website >> "Add Application"
- Alias "ContentServer"
- Application Pool > Select "AppPool_SAP Content Server"
- Physical Path "d:\sap\ContentServer"
- Click "OK"

5. Double Click on the website > Handler Mappings
- Select "ISAPI.dll" from the list >> Edit Feature Permissions
- Check the tick boxes for "Script" and "Execute"
- Click "OK"

6. Double Click on the website > Authentication
- Enable "Anonymous Authentication" (if it isn't already)
- Enable "Basic Authentication"
- Enable "Windows Authentication"

7. Double Click on the IIS Server name > ISAPI and CGI Restrictions >> Click on "Add"
- ISAPI or CGI Path "d:\sap\ContentServer"  > selecting "ContentServer.dll"
- Description "ContentServer.dll"
- Check the tick box "Allow extension path to execute"
- Click "OK"

8. Add rules to the windows firewall (ingoing port 1090 and 1095 if you are doing cache server too)

Lo and Behold: One running website with Content Server. And DO remember to set the storage somewhere you have enough space :)

As you may be able to imagine, the Cache Server .dll is very much the same steps.

Weird connection requests to xxxx.wdf.sap.corp in the ICM trace

Maybe you have seen one or two systems that for whatever reason fills up your wonderful log with totally useless information.
One of the more annoying ones, is when SAP accidentally leave stuff in place that should never have gone into a customer system. One of these is when you see messages like:

[Thr 139801848358656] Sat Nov 19 01:19:34 2016
[Thr 139801848358656] *** WARNING => Connection request from (8/9/0) to host: hs2086.wdf.sap.corp, service: 2000 failed (NIEHOST_UNKNOWN)
[Thr 139801848358656]  {00081aac} [icxxconn_mt.c 2108]
[Thr 139801845188352] Sat Nov 19 01:24:33 2016
[Thr 139801845188352] *** WARNING => Connection request from (7/8/0) to host: arcdev.wdf.sap.corp, service: 1080 failed (NIEHOST_UNKNOWN)
[Thr 139801845188352]  {00081abe} [icxxconn_mt.c 2108]
[Thr 139801845188352] Sat Nov 19 01:29:34 2016

These will populate your ICM logs, and clog them up forever if you dont do something about it.

Now, the smart person might quickly realize that these are http connection requests (why else would they be in the ICM ?), and you may even have guessed (either based on the name or the port) that this is a content service of some kind. But when you go to transaction OAC0, there are tonnes of SAP standard stuff in there. Which one is it that you need to get rid of ?
Well, fortunately, the answer is simple. Go to transaction CSMONITOR, fold out the "ContentServer", and keep folding out, untill you see the names of the archivelinks. (in a netweaver 7.3, it is usually named A2 and B2)
then simply go to transaction OAC0 and mark and delete these two offenders

S_RFC_ADM.... the auth check we all love to hate

So many times since SAP decided to create the S_RFC_ADM, but also choose not to include it in the S_A.SYSTEM role, I have hated having to do usually BI data source stuff. So often I have to re-create an RFC destination, and in so many source systems I just dont have a role that contains the ability to create an RFC destination.
Ofcourse I can wait a week or two for the auth guy to make me one. But often times the users dont really sympathize with my plight when I tell them how hard it is to get access.
So my little workaround: In most systems there is an authorization to maintain archivelink. I ask for that instead. It's usually much simpler to get a default auth, than to have a custom one created.

the auth in question is S_AL_ALL. and it contains "just" the ability to maintain RFC destinations, and archivelink destinations. Perfect for my needs.

SAP application giving HTTP error 403.2 - Forbidden

You may have seen a screenshot like this a few times in the past.

It's fairly common when you run peripheral services for your business suite on a windows environment. Maybe it's TREX, maybe it's a content server, maybe something entirely third.

And the cause is rather simple: Microsoft supports the use of ASAPI extensions and filters, but prefers that you use modules instead. So the IIS has ASAPI disabled by default. But SAP is "old" technology, so they don't change, just because Microsofts recommendation does. So the trick is to simple enable it.
If you are running server 2008, start the server manager, go to roles, click on the webserver IIS, and in the right hand pane, scroll down to role services. Here you enable ISAPI extensions, and ISAPI filters.
Reboot the server, and notice the difference !

Now, if the difference is you get a permission DENIED instead of forbidden, you may also want to look at if your service user actually has the rights to access files in the virtual directories.

Automatically starting SAP after reboot of windows

SAP was never really made to run on Windows. We all know it, we all accept it, and we all have to deal with having a couple of IDES, or sandbox systems, or even just something from old times on a windows server somewhere. Maybe you are even one of those people who have an entire suite of SAP systems on Windows. So you will be even more annoyed by the tedious AV, patching and update process, that just continually needs to reboot "your" server.
So you have to get weird calls at odd hours about SAP systems not running, or even go through the tedious process of starting the systems manually after every reboot. That takes time. Lots of time.... But it really doesn't have to.
First step is to create a batchfile that does the actual starting of your SAP system. It's fairly simple actually, you just use the sapcontrol.exe
My script looks something like this:

D:\usr\sap\SID\DVEBMGS00\exe\sapcontrol.exe -user sidadm password_here -nr 0 -function Start
D:\usr\sap\SID\DVEBMGS00\exe\sapcontrol.exe -user sidadm password_here -nr 1 -function Start

the number after the -nr parameter is the instance number on the host. You may also have a hostagent that needs to start. remember to add your SID, SIDadm user and his password. Tehnically, you may want to elevate the script to be able to run without using a user/password, or even create a dynamic script to adapt to the use of a changing password, or even consider creating a service user that only runs this script. But for demonstration purposes, this is fine. test your script by closing down the SAP systems in the MMC, and start them again with the script.

On Unix we can simply put in a startsap call at the boot time. But Windows seems to implement this much differently. So how do we run the script once windows starts up ? you may have tried the startup folder, or even added a script to the boot sequence in regedit. And you have likely failed.
But it is actually rather easy. Use windows task scheduler.

You just have to use these settings: 

* Run whether user is logged on or not

* Begin the task at startup

* Delay task for 1 minute (otherwise your database will be down, and the process will fail)

* Action start a program (browse to your script)

And hey presto.... You dont need to get up at night for a virus definition update.

If you want to be very sure, add a pause in your script, and call the sapevt and run a DBcheck (or whatever automated process you may have for validation), followed by a mail or text to your phone. 

Do note that shutting DOWN the system wont be this easy. So if you want to avoid have to "massage" your DB back to life after an unexpected powerdown, you may also want to consider automating the shutdown of the instances (and the DB service).

Patching without using solution manager

Ohhhh, I was so miffed the first time I ran into the idea that you HAD to use solution manager to patch your SAP systems. I knew SAP at some point in time would do something to force adaptation of this horrible bastard technology. But I was cross when I found out it had to be in the basis functions.
Dont get me wrong, when it works, is correctly configured, and you have a decent change and support porcess to mirror the processes within the maintenance optimizer, it does mean you dont have to read tonnes of notes about package dependencies, or the likes. A calculated queue is easily created, downloaded and applied.... IF the process works as supposed. I have never seen that happen even ONCE in the last 6-7 years I've worked with the maintenance optimizer.

And if you just need to download 4 packages and get on with your work, it would be nice to be able to skip the MOPZ entirely.... and you can !!!!
Simply find the packages you need as usual, now they will be in the "waiting for approval" step in your download basket, because.... Well, that's how SAP forces you to use solman. Now simply go to solman and run the se38 report /TMWFLOW/MO_UI_BASKET_AUTHORIZ
And voila. You can now approve the basket. Go back to the downloadbasket, and start downloading, and apply packages they way we have done it the last 25 years...