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...

Gaining access to a client without restarting SAP

The other day I was in a meeting with a supplier. We were discussing responsibilities of joint systems among other things.
It turned out that we both thought the other side held the usernames and passwords to the technical SAP clients. And much to my surprise, what was thought of as a problem, was not that noone were responsible, but that noone knew how to gain access to the clients without restarting the systems, which was problematic, as the manufacturing systems needs to be running 24/7.

Well, technically, noone in that room knew, besides me. Because I have in the past used a small oracle script to gain access to clients where the passwords to users had been lost.

The cause of the problem is that the SAP function of the no_automatic_user_sapstar parameter requires that we activate that parameter, in order to be able to login with the default user. and that means restarting the system. And once access was gained, another restart would be required to set the parameter back. This functionality is onnly meant to be used for creating a new client, so ofcourse it is not very conveniently built.

So to circumvent the issue of the restarts, I shared with our supplier, this little Oracle script they could run to gain access into client 001, without restarting the SAP system. We have Admin access to the Oracle, so ofcourse we can simply manipulate the data in the database:

rem This part will reset the lock incase you accidentally locked the user trying to get in
UPDATE sapsr3.usr02
   SET uflag = 0
WHERE mandt='001' AND bname='SAP*';

rem This part will take the password from client 000s sapstar user and give it to the same user in 001
UPDATE sapsr3.usr02
   SET bcode = ( SELECT bcode FROM sapsr3.usr02 WHERE bname ='SAP*' AND MANDT='000' )
WHERE mandt='001' AND bname='SAP*';
COMMIT
;

Now the only real downside to this approach is that we have now only changed the data on the database. Not in active memory. Well, depending on the release version of SAP and whatever parameters you have set, it may be loaded into memory when you access it.
I would recommend trying to logon with the client 000 password, if you have tried this and you fail, likely it is because the data hasn't migrated into memory yet. We can fix that by simply calling the transaction /$sync as any user and in any client you have access to.

But try to run this transaction at low usage periods. It can kill a lot of cache.

Enjoy carefree access to your technical clients.

SRM system showing approval mail with saphtmlp link

The other day, one of my colleagues came over to me and asked my why our approval emails sent out to all the managers had a weird logon link in them
I logged on to the system and said, "what do you mean ?". As I saw nothing wrong.

"Well", my colleague replied, "when I look at the properties of the mail in SOST or SOSG, it contains a lot of weird stuff in front of the actual address, but when I remove that it works".

I looked, and I saw what he meant. There was a reference to the sap HTML viewer, even the approval link had the sapevent infront of it. And the reason for sending out these mails was exactly to be able to send them to someone without access to SAP. I pondered this for a while, and I looked at notes, read documentation. Then it occured to me - But if we hadn't changed this in the last 6 months, then why had noone complained ?
So on a hunch that SAP would render this differently in SOST than after transmission, I asked my colleague to get a hold of a mail from one of the recipients. And lo and behold, SAP DOES infact render this differently when viewed from within the SAPGUI. The links were perfectly created in the mails people recieved.
Note to self: Ensure the ability to test as an end user.....

SMQS scheduler status shows RES_LACK

Today I was confronted with the fact that our BI system wasn't reciving data from our R3. After a short investigation, I found that the IDOCs were not processed. Manually processing them sent them to the tRFC queue. However, from here they just ended in "transaction recorded".
From past experience I knew to check the registrations in the SMQS. However, today I was met with a weird situation. The registration was fine, but the scheduler had a weird status.

After a while of looking, I noticed that the "host ID" was that of another system (!)
My suspicions immediately went to last weeks homogenous system copy. So I went through every step of the RFC process, from data creation to the REF destinations. And lo and behold.... the RFC logon groups (RZ12) had not been configured. Simple fix, furtunately.

SAP line opener showing correupted XML file recieved

If like me, you are forced to use an archaeic line opener, that cannot even run as a service. You may on occasion run into problems, and wonder why there is no support to get. And in truth I cant tell you. Sometimes I get angry and just continuously ping the sapserv1 server, and then go home, knowing that things are working, but saddend by the fact that it's not running optimally.

However, at least one function I have managed to find a solution for. I frequently got the error:

Error: 04-08-2014 09:44:38: Function startProcess : Corrupted XML file received
Error: 04-08-2014 09:44:38: parseXML: non-XML file
04-08-2014 09:44:38:  begin of make_https
04-08-2014 09:44:38: Getting SAPRouter data for LOP in the SMP

I tried reinstallting the LOP, I tried using a different user, I've tried pretty much anything, but it never worked. Untill I found out that it was caused by the company proxy. Not that the proxy itself poses a problem, but the way SAP tried to connect, isn't entirely compatible with modern proxies (You will know this if you have ever tried to replace a SAP webdispatcher with a real reverseproxy).

So how did I resolve the problem ? Simple. I just logged into the SAP marketplace from the server running the LOP. Then the proxy information is passed correctly by IE, which also means the LOP wont have to.

Logical system name for this BI is not allowed

Following a homogenous systemcopy of our BI, we were following the normally outlined strategy from SAP regarding copying BW/BI systems, in SAP note 886102.
In this case, however, a successfull, albeit very fast run BDLS job, resulted in the following error message when attempting to rename the logical system. Even SAP were unable to provide a timely solution to the problem.

This was, in retrospect ofcourse caused by the fact that the BDLS job only LOOKED successfull, but in fact stopped after only a few tables. One of the tables was ofcourse the T000 (which meant that the client would try to use a logical system name which didn't correspond to the technical name), aswell as the DBLS table(s). So everything looked to have finished ok. There also wasn't any error messages.

The trick was, how could I see that the job actually hadn't doen what it was supposed to ? BDLS runs for other logical systems ran just fine, and this had never been an issue in the past. I had to run a debugging of the BDLS transaction.

I had in the past had many discussions with a colleague about the BDLS functionality. I said there was a dynamic program containing the fields to be converted, he said that all fields defined as "logsys" would be converted. It turned out We were both only partly right. There IS a program, which creates a dynamic mapping of all the fields containing the logsys. And then the conversion starts based on this BDLSMAP. However, there apparently isn't any controls available to determine if this mapping fails. and in my case it did.

So I ended up finding a service program for the BDLSMAP that could clear the mapped data, After running that, the BDLS run finished fine, and all of our logical system problems went away. I'm seriously considering if this program, RBDLSMAP_RESET shouldn't ALWAYS be run prior to a BDLS run.