MIIS newbie tales – episod 1

I’m not MIIS expert, as I started working with MIIS projects few months ago, so maybe I will not post very advanced posts regarding MIIS in short time but I want to share with some field experience I had with MIIS. Today I want to give some hints about three problems one can came across using MIIS in different scenarios. I know that most peoples who work with MIIS projects for some time know these things, but maybe there is few MIIS newbie as I am and these hints may be helpful. First thing is a problem with Oracle connection in more secure environment. I was pushing to production my first MIIS project which was provisioning of Oracle users and roles based on employee permissions stored in MS SQL. Everything was working just fine till the tests in real environment which was one of Polish Corporation. I loaded extensible MA using OLEDB to connect to Oracle database (some kind of universal DB MA) and I tried to import data from Oracle – which was not successful. After giving the double check to my configuration I started to investigate this with some tools (regmon and filemon from SysInternals as always rocks) and I find that the problem was in NTFS permission to Oracle OLEDB driver. God knows why Oracle driver requires Full control permissions to two files located in <oracle client>\bin\ folder, which are:

  • OraOLEDB.tlb

Your MIIS service account has to have Full control to these files, if not Your connection to Oracle DB will fail. This was tested few times for Oracle 9.2.x.x client.

Second, when You need to connect in secure way to some data source and You are using SSL secured connection for this purpose You have to verify SSL certificate used for this connection. So You need root CA certificate which was used to sign Your data partner certificate to be trusted root, and here comes my advice. My friend spent some time trying to troubleshoot connection problems with SunONE directory using SSL and it turns out that this is certificate validation problem. He imported the root certificate to his account (because he was logged on to the server console), and this has to be imported to the certificate store of MIIS service account – obvious, but sometimes it can produce a problem.

Last one – how to fix problem with PCNS (Password Change Notification Services) when there is a problem with pushing out single password change from the queue which prevents the rest of passwords being synchronized. PCNS works as a FIFO queue and it may happen that for some reason queued password change can’t be pushed out from the queue. This prevents synchronization of other password to occur and Your password queue can grow, which may produce serious business problem (user’s passwords are not in sync in different systems). What You can do in this case is to determine current queue length and then use PCNSCFG.EXE tool to set queue length to the value <current length>-1 which will remove blocker from the queue. Little warning here – when You do this you have to be sure that there will be no new password synchronization request coming from the DCs because during this operation You can loose some passwords which were queue between the time You checked the queue size and the operation of resizing the queue occurred.

That’s all in this episode of “MIIS newbie tales”.

4 thoughts on “MIIS newbie tales – episod 1”

  1. Hi Tomek, Cool thread 😉 Very clever solution with PCNS problem, i did not find any solution but doing a "pcns /delete target" that kills my target and empties all the queues -> not wise enought :(. So i will follow your advice about resizing the queue lenght -1. But u said "….you have to be sure that there will be no new password synchronization request coming from the DCs..": how to be sure of this ? stop the pcns service in that DC and resizing the queue lenght -1 ? Cheers, Yann

  2. Hi Yann, jup, this is a problem – there is no way to be "absolutely" sure about this, this can be done very quickly but of course You may get into situation when some password will be lost. I e-maile more expirienced person about it (thanks Bruce) and I got another solution which may be a little safer – instead of cutting the last password with a length of queue, You can use PCNSCFG to change max age on the queue to the value which will drop the blocker password, and very quickly rise this value back to some higher value. The same result, lesser possibility that You will lost some new change password notifications.

  3. That's it ! I had the opportunity today to implement Bruce's solution and that works perfectly without any issues about losing password changes from users… that impressed a lot my boss…. :o) Thanks Tomek and we are eager to read your "MIIS newbie tales" trilogy ! Yann

Comments are closed.