Not really answering the question, but you will have problems if these
administrators do not have permission to view the sites/subsites in
question.

My guess is that you'll need a custom web part that takes advantage of
the SharePoint API model, but I'll let someone who knows more about
that respond.

DeliverPoint provides a security trimmed treeview with segment
thresholds for very large collections.

If you want to build your own webpart  you can try the following. Its
code for a webpart. I dont know how much you know about developing
webparts etc, so ask if you want to know more. The code loops all
sitecollections and its sites  in the current farm. It uses the
systemaccount (RunWithElevatedPrivileges). So it renders all sites
and subsites. The security can be managed by setting permissions for
the webpart in the webpart library. The webpart renders a tree.

I have tried it very fast - so maybe I've missed something. Hope it
helps. I dont know if this was what you were looking for.

using System;
using System.Web.UI;
using System.Xml.Serialization;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

namespace MyCompany.SharePoint.WebParts
{
[XmlRoot(Namespace = "MyCompany.SharePoint.WebParts")]
public class SiteTreeWebPart :
Microsoft.SharePoint.WebPartPages.WebPart
{
protected override void RenderWebPart(HtmlTextWriter output)
{
String html = "";

SPSecurity.RunWithElevatedPrivileges(delegate()
{
SPWebServiceCollection webServices = new
SPWebServiceCollection(SPFarm.Local);

foreach (SPWebService webService in webServices)
{
foreach (SPWebApplication webApp in
webService.WebApplications)
{
foreach (SPSite site  in webApp.Sites)
{
html += this.GetSubWebsHtml(site.RootWeb,
0);
}
}
}
});

output.Write(html);
}

private String GetSubWebsHtml(SPWeb web, int level)
{
String html = "";

html += "<ul>";

html += "<li>";
html += "<strong>" + web.Title + "</strong>" + " (" +
web.Url + ")";
html += "</li>";

foreach (SPWeb subWeb in web.Webs)
{
html += this.GetSubWebsHtml(subWeb, level + 1);
}

html += "</ul>";

return html;
}

}
}

I think that helps a lot. Just out of
curiosity, why did you use SharePoint webpart  as opposed to ASP.NET
webpart (System.Web.UI.WebControls.WebParts)?

Actually I tried with "System.Web.UI.WebControls.WebParts.WebPart"
and overide the Render method instead of RenderWebPart. But I got an
exception. I dont remember exactly but something like "Cant add a
webpart to this webpartzone". You can try to see, inherit
from "System.Web.UI.WebControls.WebParts.WebPart" and put the
RenderWebPart code in a Render method.

Maybe someone else can explain. Because I've also heard that you
should be able to run standard webparts in WSS 3.0 / MOSS 2007.

I tested the webpart  in MOSS 2007 environment - so you know, but it
should work in WSS 3.0.

For that you object model you should be using the RenderContents method
instead of either the Render or RenderWebpart method. I've done both
SharePoint and System.web webparts and they both work.

Can you use the same *.dwp or do you have to rewrite it when
inheriting from System.Web....WebPart?

Ok, I took a look in the SDK

Inheriting from System.Web....WebPart is recomended. The following
topic in the SDK explains how to build it:
msdn2.microsoft.com/en-us/library/ms415817.aspx

So you should be able to rewrite the code I sent you by following the
steps in the SDK.

But maybe you should use RenderContent instead of Render. I cant say anything about this because I dont know.

You are correct that the System.Web....webpart is the recommended one.
There are about 7 reasons why you would use the
Microsoft.SharePoint....webpart. Most of the reasons deal with Advanced
connections like connecting webparts across page  boundaries. But both
object classes work.

The preference would be to use a *.webpart file rather than a .dwp. But
either way you can use the same file for either ASP.NET 2.0 or
SharePoint web parts.

The code in this message shows the correct way to render a TreeView.
Concatenating strings should not be used for rendering output to the
HtmlWriter. Instead, ASP.NET controls should be used to abstract the
interface to produce output specific for the calling device. In fact, I
only use RenderContents to obtain the current value for a public
property that I set in code.

That said, even the code I'm including below has some problems:
-It always shows all sites  even if the user doesn't have access (this is
typically a no no)
-If trimmed, it is unable to show  child sites if the person running the
code didn't have access to the root site
-It is inefficient on large farms
-It will likely fail for Web Applications with thousands of child sites
-It is bad user interface design to show all sites when the number of
sites on the farm exceeds 100 or so

FWIW, DeliverPoint 2007 (DP07) handles all of these problems and more.
For instance, DP07 can show the sites that someone else has access to
that you can manage.

it seems to me that I've been forced to use .dwp for
SharePoint-based Web Parts and .webpart for ASP.NET-based Web Parts.

you can use a webpart  extension for new WSSv3-based Web Parts. But at one point I had convinced myself that the v2 Web Parts I upgraded to v3 required the .dwp extension. So, I hold to the tradition of using .dwp for SharePoint-based Web Parts and .webpart for ASP.NET Web Parts. If you look in the Web Part Gallery you will see Microsoft's own Web Parts follow that standard.