Permissions problem

[jellybean]

I'm not sure if this is a server problem or something we're doing wrong with Zoom (ASP .NET version).

When we index, we'll get errors such as "File locked: Cannot open ____" (usually the search template, even though we're not generating that).

Is it because we're using Windows Server 2008? I know Windows has really screwy security, and Server 2008 is also pretty new, so I wondered if anybody else had encountered this issue.

[Ray]

It might be, if your output directory is one of the folders which Windows tend to be tricky with. For example, the "Program Files" folder. Some other folders are accessed by the Windows Indexer (for its internal search functionality) and that can make files temporarily unaccessible as well.

Of course you should also make sure you don't have Dreamweaver or Microsoft Frontpage or Word or similar which might have the same file opened at the time. Those programs are known to occasionally hold exclusive access to the files they are using.

Can you give us the exact error message, along with the full path and filename? You say "usually the search template", does that mean some other files occasionally show this message? And if so, tell us what it is.

Also, let us know if it happens during normal indexing, or only during incremental indexing.

[Ray]

Here's an interesting related issue we found.

As you are using ASP.NET and IIS, it is worth noting that there are extra perculiarities where it is possible for IIS and the ASP.NET application pool to hold handles open across sessions (it caches the handles essentially).

What this means is that it is possible that IIS will hold exclusive access to a file until the service is restarted if it thinks one of its applications will need this file. This doesn't normally happen with other web servers (such as Apache) and CGI's.

Just now, we found a bug in our ASP.NET Native Control which causes IIS to believe it needs to hold access to the template file after running a search. So this means that if you have specified the IIS hosting folder (e.g. "C:\inetpub\wwwroot\zoomaspx\") as your output directory, and you need Zoom to write directly to that folder, it may indeed produce the errors you are seeing if you do this AFTER running the search.

This will be fixed in the next release (V6.0 build 1006). In the meantime, you can restart the IIS Applications Service to free access to the files.

Note that the other issues I mentioned above remain possible, if you are NOT writing directly to the IIS hosted folder, and if you are not using ASP.NET.

[jellybean]

Further permissions problem when scheduling

Hi Ray
Thanks for your reply

I wonder if this is related. I'm currently using the free version (test-driving for our application before we purchase Enterprise)... and we can't schedule it to index. Pressing the scheduling button at the top gives the following error:

Failed to initialize scheduler
The current user account does not have permission to access the Windows scheduling service.
Check your access rights for the current user account. You may need to be a Power or Administrator User to start the scheduler.

We've tested it on a Windows Server 2008 with IIS 7, and a Windows Server 2003 with IIS6, both with the same result. Both accounts we've tested it on are administrators on both machines.

[Ray]

You probably need to run Zoom as an "Elevated Administrator". This is explained in detail here:
http://www.wrensoft.com/zoom/support...ing.html#vista

[jellybean]

Concurrency issue?

Running the programme as an administrator works OK now, but the scheduling is still funny under Windows Server 2008 (still security issues). Do you have any advice? It seems we'll need to make a separate account with admin privileges for the indexer to do its work.

I'm also having some funny issues with Windows Server 2008. We're running the Indexer as an administrator, and there are three of us running the Indexer and changing settings. I'm not sure if the indexer has concurrency handling or not.

Just yesterday, the installation we have on the Server 2008 box stopped allowing us making any changes at all. The changes to some of the indexer settings (content filter, recommended pages, etc). We've had to manually change the text file to add new settings.

Have you encountered this before? It sounds like a permissions problem but some settings are being saved without problems. (we have an identical installation on a Server 2003 box with no such problems)

[Ray]

I'm also having some funny issues with Windows Server 2008. We're running the Indexer as an administrator, and there are three of us running the Indexer and changing settings. I'm not sure if the indexer has concurrency handling or not.

We tried to design V6 to accomodate running multiple instances of Zoom concurrently. But we haven't tested the scenario you are describing which sounds like you have multiple people logged in via Remote Desktop and running and configuring the Indexer. It should be okay in theory if everyone is using their own ZCFG files and have different output directories. Naturally, if you're trying to write to the same files, there'll be a problem.

Just yesterday, the installation we have on the Server 2008 box stopped allowing us making any changes at all. The changes to some of the indexer settings (content filter, recommended pages, etc). We've had to manually change the text file to add new settings.

Can you elaborate on how it "stopped allowing" you to make changes. Did you get a "could not save file" error when you clicked on "Save configuration"? Or something else?

If you were using build 1006, there was a bug introduced (in that build only) that had problems with picking up setting changes (it would just ignore them) for several configuration panels. Update to the latest build (V6.0 build 1007 at time of posting) for the fix from here:
http://www.wrensoft.com/zoom/whatsnew.html

[jellybean]

Best service ever

... seriously. This is the best service I've ever seen from a vendor.

I'll install the latest version and see if this clears up the issue. There was no save error -- it just didn't pick up the changes.

Does this new version require a reinstall of the msi file (for .net)?
Edit: nevermind. No it doesn't.