Read access to the Everyone group is removed after you install Exchange 2000 SP3

Article translations Article translations
Article ID: 816789 - View products that this article applies to.
Expand all | Collapse all

On This Page

Symptoms

If you send Simple Mail Transfer Protocol (SMTP) mail by using a Collaboration Data Objects for Windows (CDOSYS) application, a Collaboration Data Objects for Exchange 2000 (CDOEX) application, or System.Web.Mail on a computer where Exchange 2000 Server Service Pack 3 (SP3) is installed, you receive the following error message:
CDO.Message.1 (0x80040220)
The "SendUsing" configuration value is invalid.
NoteSystem.Web.Mail is a managed wrapper to CDOSYS that enables you to create and send messages by using the CDOSYS message component.

Cause

This problem occurs because read access to the Internet Information Services (IIS) metabase and the Microsoft Active Directory directory service has been removed for the Everyone group. This access has been removed because of a security modification in Exchange 2000 Server SP3. CDOEX, CDOSYS, and System.Web.Mail must have access to the IIS metabase to access information about the location of the pickup directory path. This behavior occurs when you use the Sendusingpickup method and if this information is not specified in the application code. Because access is restricted, the non-administrative user under whose security context the application is running cannot read this information from the IIS metabase and Active Directory.

Resolution

To work around this problem, use one of the workarounds in the "Workarounds" section.

Note The sample code for the workarounds is written in the context of an Active Server Pages (ASP) page.

Workarounds

To work around this problem, you must modify the configuration or the code. Configuration changes can be rolled out quickly, but code changes must be made more deliberately and while considering the security of the application and its resources.

Note Restoring read access to the IIS metabase for the Everyone group is not a workaround for this problem. Restoring this access reintroduces vulnerabilities that Exchange 2000 Server SP3 resolves.

Use one of the following workarounds so that you use CDOEX and CDOSYS applications after you apply Exchange 2000 Server SP3. In Workaround 1 and Workaround 2, you modify the administrative configuration. In Workaround 3 and Workaround 4, you modify the code. Although you only have to apply one workaround to resolve the problem, you must decide which workaround is the most appropriate solution for the user's application.

To modify the administrative configuration, you must selectively grant access to the IIS metabase. In Workaround 1 and Workaround 2, the application code is not changed, but the accounts that require read access to the IIS metabase are granted access. You can either grant IIS metabase access to the account that the application is running under (Workaround 1) or you can create a new account for that purpose (Workaround 2).

The Adadd.vbs, Adlist.vbs, and Addel.vbs script files grant access to the IIS metabase. See the "Appendix" section at the end of this article for more information about these script files.

Because Collaboration Data Objects (CDO) calls the RevertToSelf function before it accesses the IIS metabase, you can add the account where the application process runs. For a typical ASP page, this is the IWAM_ComputerName account.

Workaround 1

The least destabilizing option is to determine which account the applications are running under, and then grant the account access to the IIS metabase. However, because other applications may use the existing account (for example, IWAM_XXX or IUSR_XXX), this workaround may introduce vulnerabilities if these other applications are granted access to the IIS metabase. The advantage of this workaround is that the application code and the SMTP configuration are not changed. The disadvantage of this workaround is that it may unnecessarily grant access to the IIS metabase.

To determine which account the application is running under and to grant the account access to the IIS metabase, follow these steps:
  1. Save the .vbs files to a directory on your server.
  2. In IIS, locate the virtual directory that contains your application, right-click the virtual directory, and then click Properties.
  3. Click the Directory Security tab, and then under Anonymous access and authentication control, click Edit.
  4. In the Authentication Methods dialog box, make sure that the Anonymous access check box is selected, and then under Accounts used for anonymous access, click Edit.
  5. Write down the account name that is displayed by the Anonymous User Account dialog box.
  6. Click Cancel to close the dialog boxes.
  7. At a command prompt, change the directory to the directory that contains the .vbs files in step 1.
  8. Use Adadd.vbs to grant access to the IIS metabase to the account that you noted in step 5. To do so, run the following command at the command prompt:

    cscript adadd.vbs ComputerName\AccountName

    Note On a domain controller, use DomainName\AccountName, or do not specify either the computer name or domain name. You only have to provide AccountName after adadd.vbs. To add IWAM_computername on a domain controller, run one of the following commands at the command prompt:

    cscript adadd.vbs DomainName\IWAM_ComputerName

    -or-

    cscript adadd.vbs IWAM_ComputerName

    You must also sometimes grant IIS metabase access to the IWAM_ComputerName account by using Adadd.vbs. To do so, run the following command at the command prompt:

    cscript adadd.vbs ComputerName\IWAM_ComputerName
  9. Use Adlist.vbs to verify that the account was added to the IIS metabase access list. To do so, run the following command at the command prompt:

    cscript adlist.vbs
  10. Stop and then restart the IIS Admin service and any dependent services.
  11. On computers that are running Exchange 2000, grant user write access to the Program Files\exchsrvr\mailroot\vsi#\pickup directory path. On computers that are not running Exchange 2000, grant user write access to the Inetpub\mailroot\pickup directory path.
  12. Wait for Active Directory to replicate to the IIS metabase.
  13. Run the application.

    The application now works as expected.

Workaround 2

You can create an account, grant that account access to the IIS metabase, and then configure the virtual directory where the application is running to run as the account. The advantage of this workaround is that the application code and the SMTP configuration are not changed.

To create a new account for the application to run under and configure the virtual directory, follow these steps:
  1. Save the .vbs files to a directory on your server.
  2. Use Active Directory Users and Computers to create a computer account (for example, CdoExAccount), and then add this account to the Users group.

    This account does not require a mailbox.
  3. In IIS, locate the virtual directory that contains your application, right-click the virtual directory, and then click Properties.
  4. Click the Directory Security tab, and then under Anonymous access and authentication control, click Edit.
  5. In the Authentication Methods dialog box, make sure that the Anonymous access check box is selected, and then under Accounts used for anonymous access, click Edit.
  6. In the Anonymous User Account dialog box, follow these steps:
    1. In the Username box, type the name of the account that you created in step 2.

      Note On a domain controller, use DomainName\AccountName, or do not specify either the computer name or domain name. You only have to provide AccountName. If you created a computer-level account, type the account name in the following format: ComputerName\AccountName
    2. On a domain controller use <DomainName>\<AccountName> or do not specify either computername or domain name (just give the <AccountName>)
    3. Click to clear the Allow IIS to control the password check box.
    4. In the Password box, type the password for the account.
    5. Click OK, and then retype the password in the resulting dialog box.
  7. Click OK to close all the dialog boxes.
  8. At a command prompt, change the directory to the directory that contains the .vbs files in step 1.
  9. Use Adadd.vbs to grant access to the IIS metabase to the account that you noted in step 2. To do so, run the following command at the command prompt:

    cscript adadd.vbs ComputerName\AccountName

    Note On a domain controller, use DomainName\AccountName, or do not specify either the computer name or domain name. You only have to provide AccountName after adadd.vbs. To add IWAM_computername on a domain controller, run one of the following commands at the command prompt:

    cscript adadd.vbs DomainName\IWAM_ComputerName

    -or-

    cscript adadd.vbs IWAM_ComputerName

    You must also sometimes grant IIS metabase access to the IWAM_ComputerName account by using Adadd.vbs. To do so, run the following command at the command prompt:

    cscript adadd.vbs ComputerName\IWAM_ComputerName
  10. Stop and then restart the IIS Admin service and any dependent services.
  11. Run Adlist.vbs to make sure that the account was added to the IIS metabase access list. To do so, run the following command at the command prompt:

    cscript adlist.vbs
  12. On computers that are running Exchange 2000, grant user write access to the Program Files\exchsrvr\mailroot\vsi#\pickup directory path. On computers that are not running Exchange 2000, grant user write access to the Inetpub\mailroot\pickup directory path.
  13. Wait for Active Directory to replicate to the IIS metabase.
  14. Run the application.

    The application now works as expected.

Workaround 3

If you do not explicitly specify the sendusing method in the code, the cdoSendUsingPickup value is the default value. However, you can explicitly specify cdoSendUsingPickup and the pickup directory path in the code. To use the pickup directory method, the local SMTP must be configured for relay.

The advantages of this workaround are increased application control of configuration and that the workaround is not limited to the first SMTP service instance. On computers that have multiple SMTP virtual servers, the default configuration selects the first pickup directory in the IIS metabase. This pickup directory may not be the directory that the application needs. By explicitly specifying the pickup directory, you can make sure that the default configuration selects the correct pickup directory. The disadvantage of this workaround is that it is more fragile than the other workarounds. Changes to the Exchange 2000 installation or to the administration configuration may cause the application to stop working because of changes to the location of the pickup directory.
Code Sample
The following code sample demonstrates how to explicitly set cdoSendUsingPickup and the location of the pickup directory:
<%@ Language=VBScript %>
	<%
	    Dim iMsg
	    Dim iConf
	    Dim Flds
	    Const cdoSendUsingPickup = 1
	
	    'For CDOSYS, the pickup directory is located at c:\inetpub\mailroot\pickup.
	    Const strPickup = "c:\Program Files\Exchsrvr\mailroot\vsi 1\Pickup"
	
	    'Create the message object.
	     Set iMsg = CreateObject("CDO.Message")
	
	    'Create the configuration object.
	     Set iConf = iMsg.Configuration
	
	    With iConf.Fields
	  	.item("http://schemas.microsoft.com/cdo/configuration/sendusing")= cdoSendUsingPickup
	       .item("http://schemas.microsoft.com/cdo/configuration/smtpserverpickupdirectory") = strPickup
	       .Update
	    End With
	
	    'Set the To, From, Subject, and Body properties of the message.
	    With iMsg
	       .To = "someone@example.com"
	       .From = "someone@example.com"
	       .Subject = "Test message by using CDOEx and cdoSendUsingPickup sent on: "  & now()
	       .TextBody = "This is a test by using CDOEx"
	       .Send
	    End With 
	    Set iMsg = Nothing
	 %>

Workaround 4

Instead of writing messages to the local pickup directory, you can write messages to a remote SMTP server over the network. The advantages of this workaround are lower overall resource consumption and immediate and detailed error information. The disadvantages of this workaround are that the remote SMTP server may not be available and that you lose the natural queue mechanism in the pickup directory.
Sample Code
The following modified sample code works on Exchange 2000 Server SP3. Note that this sample adds code to create and set the configuration object.
<%@ Language=VBScript %>
	<%
	    Dim iMsg
	    Dim iConf
	    Dim Flds
	    Const cdoSendUsingPort = 2
	    Const strSmartHost = "MySmartHostServer"
	
	    'Create the message object.
	    Set iMsg = CreateObject("CDO.Message")
	
	    'Create the configuration object.
	    Set iConf = iMsg.Configuration
	
	    'Set the fields of the configuration object to send by using SMTP through port 25.
	    With iConf.Fields
	       .item("http://schemas.microsoft.com/cdo/configuration/sendusing") = cdoSendUsingPort
	       .item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = strSmartHost
	       .Update
	    End With
	
	    'Set the To, From, Subject, and Body properties of the message.
	    With iMsg
	       .To = "someone@example.com"
	       .From = "someone@example.com"
	       .Subject = "Test message by using CDOEx and cdoSendUsingPort, sent on: "  & now()
	       .TextBody = "This is a test by using CDOEx"
	       .Send
	    End With
	    set iMsg = Nothing
	 %> 

Appendix

To download the script files that grant read access to the IIS metabase and Active Directory, visit the following Microsoft Web site:
http://download.microsoft.com/download/9/7/0/9706f302-99f8-49f9-8aa4-df66d771feaf/smtppermissionsscripts.exe
The download includes the following script files.
Collapse this tableExpand this table
File NameUsage
Adlist.vbsLists the access control lists (ACL) for each SMTP service instance on the server in the Active Directory (if available) or in the IIS metabase.
Adadd.vbsGrants accounts read-only access to all SMTP service instances on the server.
Addel.vbsRemoves all access control entries (ACE) for the account from all SMTP service instances on the server.
Each script uses Active Directory to determine if the computer is running Exchange 2000. If the computer is running Exchange 2000, changes are made in Active Directory, and the Ds2mb.dll file replicates the changes to the IIS metabase for consumption by SMTP. If the computer is not running Exchange 2000, changes are made directly in the IIS metabase.

Properties

Article ID: 816789 - Last Review: September 3, 2013 - Revision: 6.0
Applies to
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server Standard Edition
Keywords: 
kbdownload KB816789

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com