Error c1030af7 - cannot administer virtual servers


In attempting to deal with a huge influx of spam, I am trying to configure GFI Mail Essentials to scan public folders.  We have Exchange 2003 set up, and run  Microsoft Server 2003.  I discovered through this process that I cannot administer public folders from System Manager.  In System Manager, when I click on folders, then try to expand public folders I get message c1030af7.  I have already attempted the fix in article 839744, so please do not refer me to that.  It did appear that the Exadmin virtual folder was recreated after I deleted it as they instructed.  I could view it from IIS, and go into the Properties page.  However, I could not view it in Exchange by going into Folders then Public Folders.  If I drill down from our server name, to Protocols, then HTTP, I do see it listed there.

I have done alot of research, and here is what I know thus far.  In IIS, the Exadmin, Exchange, and ExchWeb virtual servers are all within the Outlook Web Access web site which I assume is my default.  They are configured for port 8080.  We have an internal web site that uses port 80.  Finally, we have WSUS configured for port 8030.  All of this was confirmed by running the adsutil.vbs script from the command line.  

If I try to browse to http://our server:8080/exchange/exadmin I get error 404 ... though I'm not sure this is the correct way to browse to exadmin.  I can browse to http://ourserver:8080/exchange and access OWA where I was able to physically add a public folder.  This folder does appear in my Outllook user folder, but as suspected I cannot see it from System Manager. I can find no way to force  GFI to scan this public folder.  Apparently, it has to create the public folder itself.  Obviously, that's where my problem lies.  When I attempt to have GFI create the folder,  it never appears.  

Would copying the Exadmin virtual server to the site that uses port 80 fix this?  The documentaion regarding symptoms of incorrectly configured ports did not indicate that the error message I'm receiving would occur.  Therefore, I have not attempted this yet.

Any help would be greatly appreciated.
network administrator
Who is Participating?
Closed, 250 points refunded.
Community Support Moderator
Please do the following steps and do let me know weather do they help.

- Verify no host headers on the Default Website (which ever site is hosting the Exadmin virtual dir)
- Navigating to the exadmin folder in IE should give a 404 (or 503 in some cases)error once you enter credentials
- http://servername/exadmin
- If in this case, you actually get a directory listing page that shows a folder with the name of your domain
- Recreate the exadmin folder in IIS
- back up the metabase
- right click servername in IIS, All Tasks, Backup/Restore
- remove the exadmin virtual directory
- open up command window (cmd)
- cd \inetpub\adminscripts
- run "adsutil delete ds2mb" (this deletes the ds2mb in the metabase
- restart the Exchange System Attendant (this will restart the Information Store and the MTA Stacks)
- this will recreate Exadmin folder
- verify the exadmin folder has been recreated
- navigate to the exadmin folder in IE should now give you 404 (or 503)

This should resolve your issue and Public Folders should now be seen and administered in ESM.

Abhijeet Kulkarni
also if you dont know any of the above mentioned steps then please do let me know and i would provide you a indetails explanation on how to go about it.

The above resolution would surely help you to get it resolved. :)

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Below are also some more troubleshooting steps which you can follow if the above mentioned steps dont help. coz i have seen this happening many times.
and the above mentioned steps have got it resolved but if they dont help please try the steps mentioned below. if you have any doubts or questions please do let me know.

1. On the Web Site tab, Advanced button, if you don't have identities for the loopback adapter
       add one for each secured (443) and unsecured (80)

2. On the Home Directory tab, Application pool is set to an application pool whose name can be your domain name
         change this to DefaultAppPool

3. On the ISAPI filters tab, you might have a filter for stsfltr.dll,and you might not have one for fpexedll.dll, and the priorities might be wrong
         add the fpexedll.dll filter with a priority of low
         remov filter for stsfltr.dll
         change priorities to match a default installation:
      SBSFLT - high
                fpexedll.dll - Low
                OwaLogon - Low (in my lab machine this is "Unknown" by default but If you cannot change this to unknown then leave it as Low)

4. On the Directory Security tab, Auth and Access Control, edit button you might not have anonymous access checked.
         Please check that box.

Do let me know if this helps as well

Abhijeet Kulkarni
1.  On the Web Site tab, Advanced button,

         - add one for each secured (443) and unsecured (80)

2.  On the Home Directory tab, Application pool is set it to DefaultAppPool

3.  On the ISAPI filters tab,
         - add the fpexedll.dll filter with a priority of low
         - removed filter for stsfltr.dll
         - changed priorities to match a default installation:
               SBSFLT - high
               fpexedll.dll - Low
               OwaLogon - Low

4.  On the Directory Security tab, Auth and Access Control, edit button  check the anonymous box
pdowney1Author Commented:
Thanks, Abhijeet.  I had already performed the steps in your first post, and they did not correct my problem.  I"m going to attempt those suggested in your second post which are similiar to those suggested by december41991.

To ensure I'm describing the behavior correctly, I'm going to explain in painful detail what is occuring in System Manager.  I drill down as follows: Administrative Groups, First Administrative Group, Folders, Public Folders.  It is when I attempt to expand the Public Folders group that I get the error message.

I'll come back with an update.
pdowney1Author Commented:
It appears that there are no filters set up.   I was not involved in the configuration process, so I am not familiar with why things are set up this way.  Do I need to add a filter?  I actually tried to add the fpexedll.dll one, but couldn't figure out how to set a prioirity.

I added the loopback adapter identities by adding one with 443 for the port and one for 80 for the port ... no header values.  Let me know if I did this incorrectly.

I wasn't entirely sure about the Application pool name.  Underneath our server-name tab, I have a tab for Application Pool.  When I right-click on this, and click New, the window that appears to add a new application pool has a grayed out value for
Application Pool Name and it is set to DefaultAppPool.  Where else should I go to check this?

k so as of now which step are you stuck on
pdowney1Author Commented:
This is where I stand right now.  

Loopback adapter identities - I did attempt to add the loopback adapter identities as I described in my last post.  However, I then noticed that the OWA was stopped.  I assume that is because I'd entered 80 as the port for one of the loopback identities, and I have another web site using port 80 (refer to original post).  I could definitely be misunderstanding this which is why I'm here!!!!  Anyway, I deleted those loopback identitities and the OWA started up again.  So I'm definitely stuck here.  Please enlighten me on how to correctly add the 443 and 80 if NOT as a port.

ISAPI filters - we don't appear to have any filters set up on the default website.  I attempted to add the fpexedll.dll one, but couldn't figure out how to specify the priority.  Someone please enlighten me on what these filters are for, and should we have them set up??????  Guess I'm stuck on this one too.

I forgot to check the Auth and Access control setting.  I'll do that next.


pdowney1Author Commented:

I wanted to send an update on how I resolved this issue.  I had to switch the OWA port to 80, and our internal web page to 8080.  This resolved the issue.

Unfortunately, none of the suggestions I received lead me to this discovery, though I appreciate all of the help immensely.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.