As I said:
" Present the folder hierarchy and allow the user to select the (sub) folder where he wants to make the changes and grab the properties." Let the admin decide. If said admin can decide to select which folder he's going to edit a .config file in, why can't the UI allow him to do likewise? -sc From: Ken Schaefer [mailto:[email protected]] Sent: Thursday, August 18, 2011 10:03 PM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 You can always get the cumulative settings for a folder. Where are you going to save the settings? From: Steven M. Caesare [mailto:[email protected]] Sent: Friday, 19 August 2011 1:35 AM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 The tool doesn't have to make the choices for you. Simply present the choices. Present the folder hierarchy and allow the user to select the (sub) folder where he wants to make the changes and grab the properties. ACL's prevent you from making changes where you don't have perms. -sc From: Ken Schaefer [mailto:[email protected]] Sent: Thursday, August 18, 2011 1:24 PM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 GPOs can be linked at multiple places - but by default only Domain Admins can do this - they have visibility of the entire AD Anyone can stick a web.config file in their folder - IIS7 natively has a distributed administration model (unlike IIS6 - where you needed to be an admin to do things). So anyone with a hosting company can upload a web.config to their root folder. And they can sub-delegate to other people who can put a web.config in their subfolders. And so on, ad infinitum. So, when editing the settings for /Default Web Site/AppRoot/SubFolder where should the settings be saved? applicationHost.config? the web.Config in the website root? The web.Config in AppRoot folder? Or the web.config in SubFolder? This all depends on who is doing the editing, and what their intent was. There is no simple answer to this question. Cheers Ken From: Steven M. Caesare [mailto:[email protected]] Sent: Thursday, 18 August 2011 8:45 PM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 Yeah, still not impossible. Have "scope" selector that decides if the address restrictions (or whichever parameter is in question) apply to the local page, the entire site, etc... and then have the GUI tool default to making changes in a sensible location that work by default. If somebody wants to go add/change afterward via command line, so be it. Heck, GPO settings can be in a zillion different objects linked in at various places in the OU hierarchy, but there are tools to aggregate the RSOP so you can see it, and then decide where you want to change it... I feel that allowing CLI/scriptable editing of configuration data is a valuable step forward. At the same time I feel that also removing configuration tools (especially that allow "discovery") is a needless step backwards. That having been said, thanks for the pointer to the editor. J -sc From: Ken Schaefer [mailto:[email protected]] Sent: Wednesday, August 17, 2011 11:11 PM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 The main issue is: a) IIS6 - used one metabase for all sites/applications/folders etc b) IIS7 used a hierarchical set of config files - you can have a config file in every directory, plus you can define arbitrary locations (via <location></location>) in higher up files. So, the actual setting needs to be the aggregated total of all these settings in an unknown number of files. Not to say this can't be managed in the GUI - it's just more difficult (e.g. where should the changes be committed to - applicationHost.config via <location>? Create a new web.config in the local directory?) That said, there is an optional config editor add-in you can download from ww.iis.net website Cheers Ken From: Steven M. Caesare [mailto:[email protected]] Sent: Thursday, 18 August 2011 10:41 AM To: NT System Admin Issues Subject: RE: Using IP address restrictions in IIS 7 I'd suggest the two aren't mutually exclusive. Many a management GUI has just been shoving data to and from the registry for years now. This need be no different if the configuration container is an XML based config file instead. -sc From: Steven Peck [mailto:[email protected]] Sent: Wednesday, August 17, 2011 2:32 PM To: NT System Admin Issues Subject: Re: Using IP address restrictions in IIS 7 On Wed, Aug 17, 2011 at 11:13 AM, Kurt Buff <[email protected]> wrote: On Wed, Aug 17, 2011 at 08:13, John Hornbuckle <[email protected]> wrote: > Good heavens. That's progress? Yes, absolutely. > The IIS team must've taken tips from the Exchange team on removing previous > GUI features and making users work more with config files and command > prompts. That's a good thing. GUIs are terribly limiting, and don't usually allow automation, revision control, etc. <snip> Kurt 99% of people using IIS will not need or use several of the more esoteric features either so getting them out of the GUI reduces opertunity for people to break their installs in weird ways. Steven Peck http://www.blkmtn.org ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
