Complicated Question 2

[gregarican]

Perhaps not technically complicated, really more complex in terms of different components. I have a 64-bit Windows 2008 Server with IIS 7.0 running. This server is going to replace an older 32-bit Windows 2000 Server that's currently in production.

One of the roles the new box will have is hosting up Crystal Reports. These reports were hosted on the old box through its IIS service. I have installed the necessary CR redistributable files on the new 2008 box and most of the SQL-based reports are working fine.

The problem is when I try to test out the Foxpro-based reports on the new box. Previously these reports had an ODBC data source on the old box. Well, from what I've gathered apparently there aren't any 64-bit Foxpro ODBC drivers.

So I recompiled these reports to use the Foxpro OLE DB provider instead. For the data source I point the OLE DB provider to the full UNC path to the Foxpro data directory. This works fine on my development machine. But when I test things out on the 2008 box I get a CR message back stating that the requested page requires logon credentials. That's CR's way to complaining that it can't physically connect to the data set. Because there are no logon credentials. It's just a publically shared directory that everyone has access to.

This might be the wrong forum to post my question in, but it appears as if it's a permissions issues somewhere in tbe belly of the IIS/ASP.NET services. I've set the App Pool to run under a domain admin account as a test. I still get the same results. I've changed it so this UNC path is accessible to the Everyone group (not just the Domain Users group) as another test. Still the same results.

Any suggestions? Our company has a decent amount of Foxpro data on our network and if I can't mine into it using my web-hosted reports this will be a curve ball for sure!

 

[gregarican]

Okay, a follow up to my own post. This definitely appears to be a permissions-related issue. Here's another example:

I have a few dozen scheduled tasks that I brought over into 2008. All of these run fine when I manually run them at the 2008 box interactively. But the tasks that involve saving files to remote directories fail if I am logged off the 2008 box.

The tasks are script files that work fine on 2000 and 2003 boxes. I am using full UNC paths and have verified that the user account the tasks are running under definitely has permissions to the UNC paths. I chose to run the tasks under the domain admin account, chose to run the tasks whether or not the user is logged on, and chose to elevate to the highest privileges.


Still no luck. Like I said, the tasks all run perfectly when I run them through the Task Scheduler interactively. But when I look at the results of these tasks when I'm logged off there are access/permission denied type of errors when the UNC paths are being referenced.

 

[biglebowski]

We've had some issues with UAC on R2, I don't know exact details but we never had the issues with 2008 sp2.

"Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary, and you can probably get a career in it.
Anything invented after you’re thirty-five is against the natural order of things."

 

[gregarican]

Here's the final outcome where I was able to resolve things. I was accessing the Foxpro data through the OLE DB Provider for Visual Foxpro. This is a 32-bit DLL and my IIS 7.0 Application Pool wasn't set to run in 32-bit compatible mode. Once I changed that things are now apparently working fine!

Another odd one that I figure I'd post in case any unfortunate soul runs into this. My 2008 box hosts a few dozen scheduled tasks. I was able to import these from my old 2000 box using the schtasks.exe command line utility. The problem was that my tasks that involved Office COM scripting (e.g. - creating new Word and Excel documents) all failed. Apparently they didn't have permissions to spawn off out of the batch files the tasks launch with.

After a few days of Googling around I finally found the root cause. Windows 2008 requires a c:\windows\syswow64\config\systemprofile\desktop folder in order for Office COM to function correctly when running under the Local System account. Once I created this missing folder I am all set. This was driving my crazy because I had the tasks configured to run when logged on or off, had them running as the domain admin account, and had them running under highest elevated privileges. But the tasks still wouldn't work, although I could manually run them from the command line on the 2008 box.

Anyhoo, that's the wrap-up of this phase of my (thus far painful) server migration