Dispatcher Errors

Recently when working on a new QA system based on a copy of the PROD database when I encountered an error that I had never seen before when starting up the first dispatcher. I highlighted it below:

Running MxDispatcher_d1.
[21.09.2011 18:37:19-539] - Initialized log for com.sap.idm.ic.services.api.MXMCApi. Log level is Debug
MxDispatcher version: 7.10.5.2 Built: 07.06.2011 16:20:24 (c) Copyright 2008 SAP AG. All rights reserved.
Java VM: Sun Microsystems Inc.   Version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Java lib/ext: C:\Program Files (x86)\Java\jdk1.5.0_22\jre\lib\ext
CLASSPATH: d:\sap\idm\Java\mxdispatcher.jar;d:\sap\idm\Java\mxmcapi.jar;D:\jdbc2.0\sqljdbc_2.0\enu\sqljdbc.jar;
[21.09.2011 18:37:19-557] - MxDispatcher:Reading prop files
[21.09.2011 18:37:19-557] - MxDispatcher:Loading driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
[21.09.2011 18:37:19-639] - MxDispatcher:Creating connection to : jdbc:sqlserver://NWIDMSBX:1433;databasename=mxmc_db;user=mxmc_rt;password=********
[21.09.2011 18:37:21-369] - MxDispatcher:Reading main MxDispatcher configuration ...
[21.09.2011 18:37:21-593] - MxDispatcher:Dispatcher configuration d1 not found
[21.09.2011 18:37:21-594] - MxDispatcher:Error reading main MxDispatcher configuration ...
[21.09.2011 18:37:21-594] - The first config load failed:Dispatcher configuration d1 not found

I went through all of the normal dispatcher configuration checks, JAVA configuration, drivers, and database configuration. Everything looked OK, My ODBC checks were ok, and I knew that I was contacting the database server and that the ports were open. One suspicious thing was the extremely long length of the dispatcher name, however was not the the cause.

What we actually found was that the server names were not correct after all. The ODBC connection was pointed to the correct server, but the Java runtime connection was to the wrong server. Nothing like the confusion in moving configurations from one environment to another!  After ensuring once again, that I had the correct configuration, I regenerated the dispatcher scripts and all was fine.

So the cause of this error is when there is a connection string mismatch if you should see this in the future.

Fitting It Into the Schedule

This title applies to more than one aspect of my Identity Management life these days. I've been very busy which accounts for the lack of blog entries lately.  It's not that I don't have what to write about.  It's more about finding the time to do it.  

I was given an interesting challenge lately.  We have a number of tasks on the current project that only need to run once a month., which is not a frequency that is supported by the IDM scheduler. There's actually a few ways to handle this. Most of which revolve around finding the batch file that is created when job is first run and tying this into the scheduling utility of your choice.

However, I was really interested in finding a way that would work within the IDM framework. So I came up with this little script:

// Main function: scheduler

function scheduler(Par){

//Only run the task on a particular day of the month.

//Should only be called from the Initialization script of a maintenance job.

//Created by: Matt Pollicove 7/7/11

//NW IDM Functions used in this script:

//uStop();

//uGetPassSubject();

//uWarning();

//*****

//NOTE: Requires an external Job Constant called Runday that is set to the

//two digit day of the month that the task should be executed on or this value

//must be hard coded

//Parameters for the task.  Name of the pass/task and what the legal execution day is

var strJobName = uGetPassSubject();

var strRunOnThisDay = '%$runday%';

//What's today's date and what is the actual date.

var strDate = '%$ddm.date%';

var strToday = strDate.substring(3,5);

//Put it all together

if (strToday != strRunOnThisDay){

     uWarning(strJobName + " is not scheduleItd to run on " + strDate);

     uStop();

}         

}

As you can see, it's not terribly complicated, but let's break it down:

The task first grabs the name of the running task for informational purposes.  Then it goes out to find a local constant (feel free to make an adjustment so that it works with a repository or global constant) which holds the day of the month the task should run on.

Once we have this, we do basically the same day with the current date, by getting it from the system parameter %$ddm.date%, and retrieving the date part of the current month.

Then we can compare the two values. If they're equal go ahead, if not, we log a message (another thing that can be taken out if desired) and call uStop().

1. Now to use this functionality we need to do the following:
2. Copy/Paste the script listing above into a NW IDM script.
3. Create the RUNDAY constant.  Remember if you choose to create this as anything other than a job constant, you need to edit the script accordingly.
4. This script could be used in either a managed task (yellow folder section) or a work flow task (although I'm not sure why). But the script should be placed in the "Initialization script" entry on the source tab of the first pass in the job. When running as a managed task, it should be scheduled to run once every 24 hours.

That's about it.  Hope this works for you.  Please remember to share any edits or improvements.

IDM MMC Navigation Tip

Ok, I won't make this all about the problems with the MMC Console.  We all know what they are. However, one thing that's always ticked me off is navigating through a long list of attributes or scripts.  If that list gets to be too long, it turns into a scrolling list. Of course good naming conventions help, but we'll talk about that another time.

Quite by accident, I discovered that you can click on the list of attributes then scroll through with the arrow keys, and more importantly, if you go to the very top, you are automatically brought to the other end of the list so you can keep on scrolling.

Hopefully this will save you some time, effort and aggravation!

If you didn't write it down, it didn't happen!

We've all been there. It's crunch time. Where did the time go? Weeks of requirement gathering, architecture, development, unit test, integration test, and now go-live with a whole bunch of dependencies and C-level attention is right on top of us.  There's only time to address the last minute issues.

Throughout the project, the PM has been screaming for documentation.  Where's the completed architecture  Where's the test plan that you said you worked against? How about a run-book? And on, and on and on...

Too many architects, leads and engineers regard documentation as a necessary evil at best. Until it comes time that YOU are the one inheriting the project and YOU have to try and understand what some guy did in the past.  If you're really lucky, you know the guy or he's still with the client, or maybe even your practice if you're a consultant.

We all seem to forget that documentation is just as important as any piece of code, fancy database query or complex workflow.  It's the basis for the whole project.  It needs to be focused on just as much as any piece of development or testing.

The fact is, if you have a good design, any engineer can build the solution.  If you have a good test plan, the QA meeting flies right by and the change control board meeting becomes a coffee break rather than a Homeric battle to prove that your solution is up to snuff.

It also benefits you as an architect/engineer/consultant.  If it's written down, it's easy to reference for future work.  Remember, when you're sitting in the corner office as the CIO and someone comes up to ask you "back when you were the IDM lead, how did we do ... ?"  Well if it's written down, you'll know!


What ticks me off even more, is that it's SO easy to create even basic documentation in NetWeaver IDM. Fill in the documentation tab for tasks and folders with a few notes, references and examples. Put some comments in your scripts and then run the system report.  The most you might have to do is install the MMC console on your desktop so that you have access to Office. Then just run a bare bones system report.  Voila!

Just in case you haven't figured it out, I have inherited Phase II of a project with sparse technical documentation and everyone involved in this Phase is paying for it. In reality this is seldom any one person's fault.  There's limited time and multiple pressures as I mentioned in the opening of this essay, however that needs to stop being the excuse.

Based on the lack of documentation created in the past, there's increased attention on design and architecture documents, so at least the lesson has been learned in this situation.

It sure would have been easier to write if there was even some documentation.  Now I'm living in a world where nothing was written down, so I don't know what happened!

It’s Iteration Time

Recently, I had an interesting problem presented to me today that I was able to solve using a seldom used piece of IDM functionality.

The project I am working on had a requirement to read some information in from Active Directory and write it into IDM, but with a twist,  we only needed to get information from certain OUs, about 30 of them.  With this many, it did not make sense to write a separate pass for each and every OU.  That would be unwieldy and a complete pain to administer you’d have to make a new copy of the pass for each OU to be added or delete the pass if it should be removed, too much room for making a mistake. Now if IDM could somehow iterate through the list, we'd be set!

Instead, one of the talented people on the project built a PowerShell script to create a list of OUs that need to be processed and dumps it to a text file. IDM can execute this script using a Shell execute pass.  When it’s done we take that output and dump it into the database using a From ASCII pass.  Now here’s where the fun comes in…

The next pass is a From LDAP pass as one would expect in a reconciliation process. However we’re going to set it up a little differently by using the “Advanced” button to set up a process by which we can iterate through the OUs that we just moved into the database table from the PowerShell script.

To start, configure the Pass as you usually would, set a repository; populate the login name, password and a starting point using one of the OUs that you will be reconciling from.  When it’s all configured correctly, go to the Destination tab and read in the Source Template, now come back to the Source Tab and hit the “Advanced” button.

Set up your database source and SQL statement as you would in any other task.  When you’re done, it should look something like this:

Note that I use a Constant to hold the database connection string.  It saves some time since I don’t have to keep generating it and provides an easy way to update everything when I move from DEV/TEST to PROD.

Now as you recall, up above we set a Starting Point based on one of the OUs from our list.  Now we’re going to change that.  Go back the LDAP URL configuration and replace the OU with the value from our query.  It will look something like this:

Now you might be wondering, why we can’t determine the Datasource Template with the dynamic configuration, well the simple answer is that you just can’t and if you try you’ll be told that it is not possible to discover the schema from a dynamic starting point. However, if you’ve configured everything correctly, go ahead and run the task.  You’ll see that you have just gathered AD User information from a number of different OUs.  Good work!

Warping Labels to Blank lines

Ahhh, to experience the joys of designing and implementing an Identity Management solution. It doesn't matter how many bugs you quash, what desired impossible functionality that you pull out of the hat, there's always that something more that's needed to make the project "Perfect." For me, as an old timer with MaXware Identity Center and now with SAP NetWeaver Identity Management, perfection lies in the user interface.

I love the fact that I don't have to know PHP to customize the UI with the migration to NetWeaver and that I can add in all kinds of neat things like tabs, lines and columns. However, I just wish that it would work a little better.

The biggest frustration I've had recently is how to get a blank line to appear in the UI. Sometimes a blank line just works better than putting in a horizontal line. Every now and then I would be able to get one to appear, but just not consistently. After a while, I began to determine some trends and after some testing I think I have the process down pat for including blank lines in the UI:

1. Create the label and put some text in it.
2. Apply the change. IDM Service restart via NetWeaver Administrator might be needed
3. Change the label text to some spaces.
4. Apply the change. IDM Service restart via NetWeaver Administrator might be needed

There you have it. I’ve found more often than not the first restart is not needed, but you just never know. As I’ve thought about what’s happening behind the scenes, my theory is that the system rejects a NULL value as a label, which is what you have when you create the label. After it’s been populated and then cleared, the value is no longer NULL. It is, however, empty and is represented that way in the UI. (Thanks also to my friends on the development team who commented on this as well)

To date, I’ve only been able to test this in NetWeaver Identity Management 7.1, SP5. I would be very interested to hear if this works in other 7.1 patch levels (it probably should) and in 7.2 (Can’t wait to get my hands on it!)

Personally, I think it would be better for all concerned if there was just a blank line object. Maybe next version…

Too much in the JAR

Recently had a problem where Import/Export was not working.  I kept getting an interesting Error Message:

What was really interesting about this was the user that was referenced, mxmc_admin.  Now this is interesting, because during the Identity Store creation process, you are prompted to use mxmc_rt as the user and there is no time during the install that you are asked to create a JAVA based connection string using mxmc_admin.

This started a great deal of troubleshooting and conversations with people who have a great deal of knowledge with IDM's moving parts. Ultimately we wound up looking at the options in IDM's MMC interface.

The problem was in the Classpath Extension. It seems in this installation we had the old Microsoft SQL 2000 JARs loading before the SQL 2005 JAR. Since the MS SQL 2000 drivers were no longer needed, I removed them, regenerated my dispatcher scripts and restarted the dispatcher services. I was now able to export without a problem. I'm saying it's the order that the JARs are ordered in since I looked at my personal sandbox system and saw that I had the following Classpath: 

And my Import/Export works just fine, thank you very much.

Some more good troubleshooting to come...

Another Blogger comes up to Bat

I was quite happy to discover a new person blogging on SAP's NetWeaver Identity Management. Ian Daniel, of Adventures in SAP IdM. Of course in Ian's case it's a Cricket Bat as he works and lives in the United Kingdom.

Ian seems to be the first of a new breed of IdM consultants making the change from traditional SAP consulting to Identity Management.  From reading the first few posts, it seems clear that he has both theoretical and field experience, which is always a welcome combination. I'm looking forward to seeing what he has to say in the coming months, and I think you will too.

Look for posts on his blog and on SAP SDN.

Welcome to the team, Ian!

Final report from Las Vegas

Sorry to say I'm wrapping my my stay here in Las Vegas.  It's been a great time to catch up with some of my friends from Trondheim Labs and SAP Consulting.  Also a pleasure to meet some folks that I've communicated with only by email and SDN from the RIG and SAP Waldorf.

I'm going to hit on two main items in this post. Best Practices and CUA.

I attended a great best practices session which talked about a number of things, most of which are fairly obvious (but still bears repeating) and a couple of interesting items.  (Emphasis is mine)

• Approach the project from the business standpoint, not from IT
• Successful IDM efforts encapsulate both technology and process, so address the initiative as a Program, not a project
• Executive sponsorship is a must
• Start with data cleansing
• Don't think that all roles need to be identified right away.  Set up the roles that are most critical and will have the biggest impact. (To be honest, I had not really thought about that one before and it makes a whole lot of sense.)

The other significant presentation I attended was on CUA.

The CUA picture has been murky ever since the acquisition of MaXware.  It's going away, it's staying, it's on maintenance... Well, you get the picture.

Based on recent reports from SAP, I think we can safely assume that it's on life support. CUA will not be further developed, and even experienced CUA hands are endorsing the use of NetWeaver Identity Management.

That's not to say that IDM is the perfect replacement for CUA.  It would seem that a fair amount of development is needed to have IDM do everything that CUA does.  However, the good news is that based on the way Identity Management works, that development will not be huge. 

Based on what I saw, organizations should begin planning on moving CUA operations to IDM, even if they are using another Identity Management system. One of the things that was established about NetWeaver Identity Management is the fact that it is the only system that can offer complete provisioning to both the ABAP and JAVA stacks for SAP.  I know that there are many partners to SAP  that offer connectivity, but I think only SAP will be able to offer a holistic approach to provisioning, particularly when provisioning to CRM and SRM. This is because the Provisioning framework that comes with NetWeaver Identity Management offers the only connectors that will work with both Technical and Business roles.

So to wrap up the coverage of TechEd, I think we can safely assume that NetWeaver IDM is evolving quite nicely and that it is in a position to gain greater acceptance from the SAP community as a whole.

As always, feel free to contact me with your NetWeaver Identity Management questions and thoughts.  I am, of course available for assessment and consulting projects.  Feel free to contact me at matt (-at-) cticorp (-dot-) com, for more information or check out the CTI website!

Talk Down, Build Up

No, it’s not a new self esteem program; rather what I think is the best methodology for developing SAP NetWeaver Identity Management Workflows.

First, let’s review the basic components of a NW IDM Workflow

Screens represent the top most level and what most people routinely deal with. Here’s where we present the attributes (populated and empty) Descriptions and other UI related features. Starting with NetWeaver IDM 7.1, this is handled by the Web Dynpro engine. Before that PHP was used.

Tasks are what give the workflow their structure. Ordered Tasks, Un-Ordered tasks, Conditionals, Approvals, etc go here.

Action Tasks are the real muscle of the workflow. Action tasks execute the actual operations of the workflow. Writing information to a Target System, a Report or the Identity Store itself all gets done from these tasks.

Of course there are many workflows of various complexities that come with the SAP Provisioning framework, but as we all know this will not cover all circumstances and sometimes custom workflows will need to be created. Fortunately, NW IDM makes it rather easy since Screen, Tasks and Action Tasks can all be linked and re-linked together over and over.

Over time I’ve found that the design and creation of workflows can be best summarized by what I refer to as the “Talk Down, Build Up” approach.

When discussing the formulation of a workflow it is generally best to discuss the workflow top down. That is start with what the user sees and then what happens after they press “Submit.” People find it easy to follow the workflow and its branches (if any) when we start from this approach. Given the way that the workflows correspond to a flowchart, this seems to be somewhat of a no-brainer. The following screenshot, gives one an idea about this:

Development, however does not work the same way. Trying to develop top down becomes fairly confusing since the developer is linking to objects that might not exist yet. Development, it seems works best, from the bottom up. In general I recommend creating NW IDM workflow objects in the following order:

1. Action Tasks
2. Privileges
3. Roles
4. Conditional/Approval/Switch Tasks
5. Ordered tasks (I seldom make use of unordered ones)
6. Screens

As a general best practice, I also reccomend using folders as organizational containers to group related tasks together. Usually I like to do this by target system (AD, SAP, SunONE, NW IDM, Notifications, etc.)

So there we have it. We talk down about the structure, but we build from the bottom up. I’m wondering how other SAP NW IDM architects approach this. What about other IdM products?

Credit Where Credit is Due!

Just in case anyone was wondering, this blog does not write itself.

I don't mean my time. I love thinking and sharing my thoughts on Identity Management in general and SAP NetWeaver Identity Center, specifically. I also get a real kick out of the comments I receive publicly and privately. It's truly my pleasure to share with you, and yes, I wish I could do it faster as well :)

I'd just like to take a moment and thank all of the people that I talk to around the world that provide me fodder for comment and sharing. I appreciate the time that people have taken to support both myself and this effort over the past few years. I don't usually mention people by name, (I take your privacy seriously) But I am most grateful for your advice and support.

Of course for those in the know, I'm always happy to buy a beer or three for my devoted advisors!

Thanks again, you all know who you are.

SAP IdM Training - Wrapup

The last day of the training was an excellent conclusion. We spent a few hours connecting to SAP JAVA and ABAP systems. In general the SAP connectors work quite well. I'll be much happier, however if the Trondheim development team creates real to/from SAP passes rather than relying on custom connectors, and of course, the end of the MMC management interface!

I also had more exposure to the new UI and as one SAP insider commented to me, what it lacks in flexibility, it makes up for in security and language localization, which I cannot disagree with. Even if a company in need of Identity Management is not a SAP shop, it should consider SAP NetWeaver IDM in environments where multiple languages need to be supported.

In general, I think the product is moving in the right direction. Looking forward to getting on some planned projects in the next few weeks, plus whatever else might come up!

SAP IdM Training Continued

Still impressed with the training class. I’ve found it interesting how they’ve been able to give the class a good flavor of how NetWeaver IdM works. I think the folks in the class are getting a solid foundation in what the product can do. Everyone in the class is looking forward to working with the SAP Provisioning framework which is the emphasis of the last day of class.

I also received a nice tip today. Take a look at this new document from SAP (I believe it is a general access document)

An interesting discussion of reconciliation from an ERP context. Most people typically reconcile against an enterprise directory, but when working with an ERP system as the authoritative source, it makes sense to have a reconciliation process against this system as well.

It's also been interesting seeing the general improvements to the product. While I miss the ease of installation, speed and flexibility of NW IDM 7.0 (Not to mention MaXware Identity Center) the new version shows better scalability than ever before. Little tweaks like adjusting the attention dispatchers should give to different task types, to improved role / management handling and event handling. The interface is not terrible and the WebDynPro UI lacks the flexibility of the old PHP, but it is a heckuva lot more functional, particularly where mutli-valued attributes , roles and privileges are concerned.

After SailPoint training and some customer facing work (gotta earn some money!) I'll be looking forward to setting up a lab environment for the rest of the IdM team at CTI. Once that's done we'll be up to giving some demonstrations to clients and other interested parties.

Long time since I ran an IdM demo...

I'll be sure to comment on the SAP Provisioning Framework sometime over the weekend.

Web UI Password Troubleshooting

I was setting up a NW IDM 7.0 SP2 Patch 5 test system yesterday and had the strangest problem. Workflow and Monitoring passwords were not being accepted. I could not log into Workflow and altough I could get into Monitoring, clicking on any link presented me with an error that I was not logged in and would be redirected to the login screen.

Now being an old hand at setting up 7.0 and previous versions I went through and checked all the obvious, IIS, permissions, PHP version.

I had some trouble initially getting PHP running but since it was now running, I did not think it could be PHP.INI, particularly since I just went through and compared it to a working PHP.INI. However since not hing else was working, I decided to take another look.

Sure enough, the path for the session directory was incorrectly specified. Changed the path, double checked the privileges and cleared all cache folders and IE cache just in case (paranoia can be a good thing sometimes) and all was fine.

Just thought I'd share...

New White Paper!

Sorry I've not posted for a while but between carpal tunnel surgery and a new White Paper on NetWeaver Identity Management have been keeping me busy.

The hand is healing nicely and the Paper has just been published. Please let me know what you think.

On a related note, I also had a brief article posted on SAP Developer Network SAP Weblogs: Identity Management.

SELECTing from the Identity Store

Now I don't know about you, but I've always had some issues with looking up entries in the NetWeaver Identity Management Identity Store. I know there are built in scripting functions like uIS_Get, uIS_GetValue, uIS_sGet, uIS_sGetValue, etc, but they've just never worked well for me. So to compensate, I've developed my own methodology for searching and retrieving items from the Identity Store.

The basic use case is this: The Identity Management solution needs to do a look up between an incoming data feed and the Identity store. The basic idea is that if the value from the feed and the value from the Identity Store match then the entries match and updating/provisioning can proceed as directed by workflow. I'm sure you can imagine other use cases, looking up managers, phone numbers, and other frequently used attributes.

The feed processing job will use a script to evaluate the match. Most likely it will pass MSKEYVALUE but could also use some other unique attribute in the feed.

The first thing that is needed is to determine the MSKEY, if any, for the entry to be worked with. To this end, I created the following query which will be implemented by NW IDM's uSelect function, which can be used in a Provisioning Job or Reconciliation task. Following best practices for NetWeaver Identity Manager, I am using the JAVA engine and therefore JavaScript in this example.

//Create an uppercase version of Par for checking against the SEARCHVALUE
uPar = Par.toUpperCase();

MSKEYQuery = "select mskey from mxiv_sentries where (searchvalue = '" + uPar + "')";
MSKEYResult = UserFunc.uSelect(MSKEYQuery);

You'll notice one of the first things we need to do is make sure we access the searchvalue correctly. Elements in this column always have their text elements stored in Uppercase, so we need to make sure that for the purposes of searching, we have an uppercase value handy. The results of this query are stored in a variable called MSKEYResult. Now that this information is available, we can now search for needed values related to this entry.

EmployeeNumQuery = "select avalue from mxiv_sentries where (mskey=" + MSKEYResult + ") and (AttrName='HR_EMPNUM)";
EmployeeNumResult = UserFunc.uSelect(EmployeeNumQuery );

With this query I can now look for a specific attribute value for a specific user and store it in a variable. At this point we should plan on returning a more nicely formatted version of the attribute so we will return aValue rather than SearchValue which is the value for the attribute as it entered into and subsequently processed by NW IDM for use in screen output, reports, emails, etc. In this example we are returning the user's Employee number.

This process might also include another query to do a count of returned Employee Numbers to protect against potential "dirty data" entries (multiple identities for the user or to many users with the same name.) If this scenario occurs more detailed searching, involving more attributes might be needed.

Note: I don't necessarily claim that this is the best or most efficient methodology for accessing this information. All I know is that it works for me and the way that I think / process information. If anyone has ideas on making this better or properly using the embedded functions listed above, I'd love to hear about it.

An IC Tip and a Lesson Learned

I was doing some research for a customer who had the following question:

How can I dynamically assign a role during user reconcilation from my authoritative source?

Here's the issue:

• IC has a defined Role called CHICAGO/DATA ENTRY/PRODUCTION that has an MSKEY of 100
• During reconcilation, the user entry from the authoritative source includes the name of the role.

We know that we could do a To Identity Store pass that includes the MSKEYVALUE of the user and the MSKEY of the role assigned to MXREF_MX_ROLE.

But that is hardly dynamic. I thought about doing a script but I did not want to get into the hassle of that, so I asked around and I got some good infomration. This can be easily done in IC. When doing the assignment to MXREF_MX_ROLE, pass the attribute holding the Role name, but encase it in < >. (i.e., <%ATTR_NAME%>)

What will happen is this: when the attribute is enclosed in <> IC knows that this is a potential MSKEYVALUE and will search the Identity store for this information and return its MSKEY.

Now this all seems very straight forward, but I could not get it working to save my life. After a lot of back and forth it was discovered out that I "fat-fingered" my test data.

Morals of the story:

1. Start with simple test data and build it up as needed, even if it does not 100% match the test case.
2. Always double check your typing

I had a chance to work with a gentleman who had worked on many of the LDAP RFCs and I asked him what percentage of LDAP errors are due to typos. He didn't hesitate in has answer: "85%". That was before he met me of course...

Thanks for all those out there who helped out and resisted knocking me silly!

SP2 and CONFIG.XML

So, I was updating an Identity Center instance last week to SP2 and I found that after the upgrade I could no longer access the Workflow or Monitoring Web User Interface.

After some investigation and inquiries, I was told to check out the CONFIG.XML file, which is one of the first places one should check when troubleshooting, that I might be missing some information.

Here's the relevant section of my CONFIG.XML:

<workflow>
<servertype>MSSQL</servertype>
<serveraddress>LOCALHOST</serveraddress>
<databasename>mxmc_db</databasename>
<username>mxmc_prov</username>
<password>Changeme</password>
<cryptkey>C:\IC\workflow\configs\KEY\keys.ini</cryptkey>
</workflow>

I did not see anything wrong here, and then I thought to compare it to a clean install of Identity Center. I found that the following lines were added:

<charset>UTF-8</charset>
<loglevel>0</loglevel>
<enable_cache>FALSE</enable_cache>
<sessionstore>DEFAULT</sessionstore>
<sessionstore_params>
<default_language>EN</default_language>
<default_dateformat>YYYY-MM-DD</default_dateformat>

So I cut this information out and dropped it into my Upgrade install. Fixed my Workflow and Monitoring Issues and I was able to finish my upgrade.

Moving on...

Working with SAP NetWeaver Identity Center 7.0 SP1

I am doing some consulting work for a company in Atlanta, Georgia for the next month. This has given me my first formal experience with IC 7.0 SP1, and my first ever experience running with Microsoft SQL Server 2005. All in all it's been a pleasant experience. The Trondheim Labs team has done some nice things to make the installation process go more smoothly and securely than ever before.

Notably good is that PHP updates go much more smoothly and do not require user intervention (do you wish to overwrite your PHP config).

Also during the SQL Server installation script, the person conducting the installation is prompted for individual passwords for mxmc_admin, mxmc_oper, mxmc_rt, and mxmc_prov. Lots of typing and verification for all the passwords, but time well spent.

What's bad about the process is that one must now download and install SMARTY separately, as it is no longer a part of the Workflow / Monitoring installers. It's pretty much a drop in installation so it's not that big a deal. I wonder if this is a bit of foreshadowing that PHP and Smarty are going away from IC?

On the down side of the installation we got a SQL error when initially logging into Worfklow which was:

PHP Warning: mssql_query() [function.mssql-query]:
message: The SELECT permission was denied on the object
'mxwv_ProvGroups', database 'mxmc_db', schema 'dbo'. (severity 14) in \dbwrapper.php on line 71 PHP Warning:
mssql_query() [function.mssql-query]: Query failed in
\dbwrapper.php on line 71

I also saw a simiar error for mxvc_idstore. The error is rather tough to spot as most of it appears behind the header graphics.

This error is specific to Microsoft SQL Server 2005 as it references the "dbo" schema. Schema level security does not exist in the SQL Server 2000.

To resolve this problem, log into the SQL Server 2005 Studio and select the Identity Center Database, then security, schemas and then DBO, permissions and then view database permissions. You will then need to grant SELECT permissions to mxmc_admin_u.

As we have a chance to do more, I will comment on it.