Currently I am testing a 7.68 installation. Everything seems to have gone smoothly except setting up Report Caster. When creating a new job for Report Caster I get an error. "Unable to log on to MRE. Return code: 1003 The User ID or Password you have entered is incorrect." I am trying to create a Standard Report task. In our other environment all jobs submitted through Report Caster were done through a single user id. In our other environment when creating a new Standard Report task the dropdown for Execution ID was already populated with this user id. In the new environment the dropdown is blank and disabled. Where do I set this configuration up. Going to Report Caster Configuration does not have a setting for the MRE user id only the EDASERVE user id.

Any help will be much appreciated.

Thanks

This message has been edited. Last edited by: Kerry,

Max,

Are you using the MRE logon to authenticate when getting into RC?

After installation, did you run the migrate utility to import the MRE ids into RC?

Check your installation guide and verify that all the steps were performed.

I am using MR logon to authenticate to get into RC.

I did run the migrate utility and import my MRE user ids into RC. I can see the same MR Administrators in the environment.

Have gone through the installation guide several times but have not found anything I've missed.

There seems to be an issue with the userid that is submitting the RC job. It does not have access to MRE.

The execution id must be valid on the reporting server. It has no relation to the MRE/RC id that you use to get into RC.

The error that you mention has to do with getting into RC and creating a schedule, not running a schedule which is what the execution id does.

You may need to open a case on this to verify that everything is kosher in your configuration.

Thanks for the help Ginny.
I think I fixed the problem.
Some how the migrate repository migrated everything except the passwords for the execution id.
I had to set the execution id passwords for each of the Report Caster users. Everything seems to be working but I am going to do some more testing.

Another problem I ran into and fixed

If you use the Migrate Repository tool under
Start/Information Builders/Report Caster 76/Migrate Repository/Extract make sure you have a current backup of dserver.xmls for the environment you are migrating from.
It is located in C:\ibi\ReportCasterXX\cfg.
For some reason it corrupts the dserver.xmls file from the old environment.
I checked and tested this two times and the file got corrupted twice.
Had to go back and reconfigure Report Caster in the old environment.

quote:

Some how the migrate repository migrated everything except the passwords for the execution id.

That is the way it is supposed to work. I learned that after I opened a case as I ran into the same thing. MRE doesn't have the operating system execution passwords. At our shop the execution passwords expire and the MRE pws do not. They are completely different entities even though the user names are the same.

I'm glad you got it working.

I spoke to soon it has stopped working.

How do I look up the operating system execution passwords for Windows Server 2003?

My 5.33 environment WF Reporting Server is started with SECURITY ON.
In Report Caster 5.33 I am using an operating system user ID and password as the execution ID for Report Caster submitted schedules.

My 7.68 environment WF Reporting Server is started with SECURITY OPSYS.
In Report Caster 7.68 I am using the same operating system user ID and password for the execution ID as those in 5.33.

Both 5.33 and 7.68 are on the same Windows 2003 server.

Everything works in 7.68 if I use SECURITY PTH or SECURITY OFF as stated in the installation manual.

Is there a difference between SECURITY ON (5.33) and SECURITY OPSYS (7.68)?

Could this be an issue with Apache Tomcat?

The 7.68 is an Apache Tomcat Standalone Installation because an Apache Tomcat IIS Plugin Installation does not play nice with a NewAtlanta ServletExec Installation (5.33).
It took me two days to figure that out.

I tried stopping 5.33 and just running 7.68 in case there was a conflict between two WF Servers using the same execution IDs. No luck.

Any ideas how to get 7.68 working with SECURITY OPSYS?

I'll continue running tests and see if I come up with anything.

Thanks

quote:

Is there a difference between SECURITY ON (5.33) and SECURITY OPSYS (7.68)?

No, not really.

What I learned the hard way is that to go from one release to the other, since the format of the RC base tables changed between the two releases, is to do the table migration and then do the basedir migration, but NOT do the sync process between MRE and RC. Your schedules will be converted and BOTUSER will have th execution passwords. Since I assume it is the same set of users, you don't need to do the sync.

BTW, I went from 5.3.3 to 7.6.2 so I have been through this war.

I was able to fix the issue my manually setting the execution id and password for each Report Caster user that had scheduled jobs.

You don't have to set the execution id and password for each report caster job just once for each user that has scheduled jobs in Report Caster.

Also the execution id and password has to match a username and password for an account that can log into the Windows 2003 Server that the WebFOCUS Reporting Server is installed on.