Thursday, October 07, 2004
AdminACL Permission Synch Problem in AC2K
In a previous post I covered a metabase permissions problem complete with work around for the IIS6 error message "Unable to get the Private Bytes Memory Limit for the W3WP Process".
This was followed up by a comment and a reference from ASP.NET Forums (Its quite heart warming to know that the occassional person gets some use out of this rather self indulgent blog). The followup comment pointed out that the permissions set on the Metabase AppPool key on the non controller server were overwritten by the controllers ACL upon synchronisation. In other words the non controller had the ACE of the controllers IIS_WPG group, which it couldn't resolve.
Unsurprisingly we were also suffering from the problem as described (though for some unknown reason we hadn't seen the error again, even though the box had been rebooted.... probably only a matter of time!).
However, I worked around it in a slightly less elegant way than using a global group as described, personally this was because (for completely unrelated reasons) I try to restrict the number of global groups we use as much as possible, but this solution will also work if you run AC2K in a workgroup environment where global groups don't exist.
My solution was to get both sets of local only SID's onto the controller for replication. On the second (non controller) server, run the command;
Metaacl.vbs IIS://<controller>/W3SVC/AppPools <local_machine>\IIS_WPG U
This will add the non controllers local machines IIS_WPG account to the remote controllers key; upon synchronisation each box will have their local IIS_WPG account and a non resolveable SID (being that of the other machine)
Of course, in the wonderful world of Microsoft, this isn't quite the end of the story. Once you run the Metaacl.vbs command, it adds the SID correctly to the remote controller, but for some god unknown reason, it also removes the controllers IIS_WPG from the ACL? To get this ACE back I used Metabase Explorer from the IIS6 Resource Kit as re-running Metaacl.vbs locally on the controller had the same effect above and removed the SID you have just added.
This may seem a little long winded compared to the global group solution, but if the tools are readily available then it is pretty quick to run through.... and it is an alternative solution that may suit others aswell.
Note: We currently only have 2 servers in the cluster, the third is to be moved across from ISS5 in the next few weeks. I am therefore unsure as to whether when running the Metaacl.vbs from a third machine will remove the ACE from the second?! I will post back once I have tried and verified this either way.
This was followed up by a comment and a reference from ASP.NET Forums (Its quite heart warming to know that the occassional person gets some use out of this rather self indulgent blog). The followup comment pointed out that the permissions set on the Metabase AppPool key on the non controller server were overwritten by the controllers ACL upon synchronisation. In other words the non controller had the ACE of the controllers IIS_WPG group, which it couldn't resolve.
Unsurprisingly we were also suffering from the problem as described (though for some unknown reason we hadn't seen the error again, even though the box had been rebooted.... probably only a matter of time!).
However, I worked around it in a slightly less elegant way than using a global group as described, personally this was because (for completely unrelated reasons) I try to restrict the number of global groups we use as much as possible, but this solution will also work if you run AC2K in a workgroup environment where global groups don't exist.
My solution was to get both sets of local only SID's onto the controller for replication. On the second (non controller) server, run the command;
This will add the non controllers local machines IIS_WPG account to the remote controllers key; upon synchronisation each box will have their local IIS_WPG account and a non resolveable SID (being that of the other machine)
Of course, in the wonderful world of Microsoft, this isn't quite the end of the story. Once you run the Metaacl.vbs command, it adds the SID correctly to the remote controller, but for some god unknown reason, it also removes the controllers IIS_WPG from the ACL? To get this ACE back I used Metabase Explorer from the IIS6 Resource Kit as re-running Metaacl.vbs locally on the controller had the same effect above and removed the SID you have just added.
This may seem a little long winded compared to the global group solution, but if the tools are readily available then it is pretty quick to run through.... and it is an alternative solution that may suit others aswell.
Note: We currently only have 2 servers in the cluster, the third is to be moved across from ISS5 in the next few weeks. I am therefore unsure as to whether when running the Metaacl.vbs from a third machine will remove the ACE from the second?! I will post back once I have tried and verified this either way.
Comments about this Post: