This forum has been moved here:
Helicon Tech Community Forum

ISAPI_Rewrite 3.0 (Forum Locked Forum Locked)
 Helicon Tech : ISAPI_Rewrite 3.0
Subject Topic: Isapi Rewrite doesn’ work on a clone
Author
Message |
filobilo
Newbie


Joined: 07 September 2011
Location: France
Posts: 3
Posted: 07 September 2011 at 3:34am

Hi,

We use Helicon Isapi Rewrite since a long, without matter.

We have make a clone of one of our server, and since we can't use the url rewriting. We have 404 errors.

We try to uninstall/install. We can edit the http.conf, but the rules are not efficient.
The rules are OK, we got the sames on other servers where it works well. (we got many servers load balanced.)

Sorry for my english.

Any Idea ?

I can give more information if needed.

Back to Top
 
Anton
Admin Group


Joined: 30 January 2007
Location: Ukraine
Posts: 10519
Posted: 07 September 2011 at 4:46am

Have you ever performed such operation (cloning) successfully?
The thing is that each node of load balancer must have its own copy (license) of ISAPI_Rewrite. Do you comply with this condition?

__________________
Regards,
Anton
Back to Top
 
filobilo
Newbie


Joined: 07 September 2011
Location: France
Posts: 3
Posted: 07 September 2011 at 7:51am

Thanks for your answer.

No we don't perform any cloning successfully cause of the isapi_rewriting.

But we try the install/uninstall and create a new register. Doesn't work.

The matter is that isapi_rewrite seems to doesn't want to change the registry of the isapi dll.




Back to Top
 
Anton
Admin Group


Joined: 30 January 2007
Location: Ukraine
Posts: 10519
Posted: 09 September 2011 at 4:18am

The matter is most likely related to issues with metabase.xml cloning.
You could find the following reply from one of our clients helpful:

"
Based on our investigation, it didn’t even seem to load the Isapi filter, but it did not error, and the process ran the page, just not the
Isapi filter.

You mentioned that you were seeing an error from aspnet that it was unable to see the private bytes. That was attributed to the fact the
IIS_WPG group was copied from another server, and therefore not recognized in the AdminACL property on the servers that had copied the
metabase.

You re-copied the working NLB1 metabase to NLB2.

You then used metabase explorer<http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17275>; to check AdminACL - and you found
it in a few different places without the local IIS_WPG group. You removed the unknown SPID from the list and then added the local IIS_WPG
group.

You added the correct IIS_WPG group to these levels, with the appropriate permissions - and after that the Isapi filter seemed to be running.

The permissions are:
1) Server level - read
2) Mainsite\filters - (read/write)
3) W3svc\filters -(read/write)
4) Appools - (QueryUnsecureProperty)

Like I was telling you, this is very likely never an issue if you’re not running in an IIS6 web farm environment and not using IISSYNC to copy
metabase settings across servers. However, if that is the case, then this issue will almost certainly exist unless the administrator is
explicitly guarding against it. In fact, Microsoft no longer recommends using the IISSYNC command because of these very issues.

Here’s a screencast of me using MetabaseExplorer to examine the permissions that are listed above.
http://screencast.com/t/nykPuQx8F1Qq
"

If it's not your case, please give some details on how you perform cloning, whether ISAPI filters load etc.

__________________
Regards,
Anton
Back to Top
 
filobilo
Newbie


Joined: 07 September 2011
Location: France
Posts: 3
Posted: 09 September 2011 at 4:22am

Hello, and thanks for your time.

Finally, we decide to not use the clone. we spend too much time in configuration compared with a full install for a server.

So we install Isapi_rewrite correctly, and it works well.

Thanks again.


Back to Top
 

Sorry, you can NOT post a reply.
This forum has been locked by a forum administrator.

Printable version Printable version