You do not have permission to send to this recipient. For assistance, contact your system administrator.

August 17, 2007


When you try to send an e-mail message in Microsoft Exchange 2000 Server or in Microsoft Exchange Server 2003, you cannot send the e-mail message. Additionally, you may receive one of the following error messages or one of the following Non Delivery Reports (NDRs):

• Access denied 

• You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator. 

• Unlisted Message Error 

• MAPI_E_NO_ACCESS -2147024891 

• Failed to submit mail message for user USERNAME (HRESULT:-2147024891) Pausing user USERNAME. (Security error – Cannot access the users mailbox.)


• You do not have permission to send to this recipient. For assistance, contact your system administrator. 

• The message could not be sent using your mailbox. You do not have the permission to send the message on behalf of the specified user. 

This issue is known to affect the following third-party products:

• Research In Motion (RIM) Blackberry Enterprise Server (BES) 

• Good Technology GoodLink Wireless Messaging 



This issue may occur when one of the following conditions is true:

     You do not have permissions to send e-mail messages as the mailbox owner in the account that you are using to send the e-mail message.

     You are running Microsoft Exchange 2000 Server Service Pack 3 (SP3) with a Store.exe file version that is equal to or later than version 6619.4. Version 6619.4 was first made available in the following Microsoft Knowledge Base article:

915358 A hotfix is available to change the behavior of the Full Mailbox Access permission in Exchange 2000 Server

     You are running Microsoft Exchange Server 2003 Service Pack 1 (SP1) with a Store.exe file version that is equal to or later than version 7233.51. Version 7233.51 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note that this fix is not included with Microsoft Exchange 2003 Service Pack 2 (SP2). If you have installed the Exchange Server 2003 SP1 version of this hotfix, you must install the Service Pack 2 version after you upgrade to Service Pack 2.

     You are running Exchange Server 2003 SP2 with a Store.exe file version that is equal to or later than version 7650.23. Version 7650.23 was first made available in the following Microsoft Knowledge Base article:

895949 “Send As” permission behavior change in Exchange 2003

Note This change was not included in Exchange 2000 Server SP3, in Exchange Server 2003 SP1, or in Exchange Server 2003 SP2. The change was implemented after release of all of these service packs. However, the change is supported in each of them. The change will be included in future service packs for these products.


If you install Exchange Server 2003 SP2, you must install the additional update to retain the new behavior. You must do this even if you already installed the version of the update for Exchange Server 2003 SP1.




Grant the Blackberry or other application’s service account the Send As permission on every user in a container or domain.

To grant Send As for the service account on a single user account, follow these steps:

1. Start the Active Directory Users and Computers management console.

2. On the View menu, make sure that the Advanced Features option is selected. If this option is not selected, the Security page will not be visible for domain and container objects.

3. View the properties of the user account and click the Security tab.

4. The service account (BESAdmin, for instance) is not listed.

5. Add the service account (BESAdmin, for instance). It will default to having Read permissions, but not Send As.

6. Note: This step is optional. The only permission the service account needs is Send As, so you can remove the Read permissions if you wish.  To do so, uncheck the following checkboxes in the Allow column for the service account (BESAdmin, for instance):


Read Account Restrictions

Read General Information

Read Group Membership

Read Logon Information

Read Personal Information

Read Phone and Mail Options

Read Public Information

Read Remote Access Information

Read Web Information


7. With the service account (BESAdmin, for instance) still selected, check the following box in the Allow column:

Send As

8. Click OK until you have exited and saved all changes. 

9. Restart the Microsoft Exchange Information Store service.

Shrinking the SBSmonitoring database

July 20, 2007

First the caveat.. the SBSmonitoring database shouldn’t be that big.. if it is …. your monitoring program isn’t running properly and purging the database as it should so rerunning the monitoring wizard is probably the best plan of action… but if you need to clean up that monitoring file… here’s some info from the newsgroups…

1>	We can simple rerun the Monitoring wizard to purge the
SBSmonitoring.mdf database. 

NOTE: After doing the following steps, the original performance and usage 
data will be removed. The server will start to collect new counter value 
from the beginning.

1. Open Server Management console, navigate to 'Monitoring and Reporting' 
snap-in. In the right panel, click 'Set Up Monitoring Reports and Alerts'. 

2. In the wizard, click 'Next'->Select 'Reinstall monitoring 
features'->Select the options if you want to receive the report e-mails. 
Check 'View the usage report in Server Management' option. If you want to 
receive the usage report e-mail, also check the option below->Add the users 
which you allow them to view the usage report to the authorized 
list->Select the option if you want to receive the performance 
alerts->Click 'Finish' button to complete the configurations. 

3. After doing the above steps, the performance and usage data will be 
reset. Please wait for 24 hours and then you will see the reports through 
the Monitoring and Reporting console.

2>	If you are using SBS Premium and have SQL server installed: 

You can use the SQL Client Utilities to try and shrink the database. In 
SBS, there is a job SBS_Database_Cleanup that is scheduled to run at 3:00 
AM everyday, to delete over 90 day old information from the monitoring 

You can manually run the SBS_Database_Cleanup job, and use DBCC 
to reduce the size of the database.

3>	If you are running SBS Standard: 

You need to use osql to connect to the WMSDE instance, and use transact SQL 
commands manually to request the database be shrunk ("dbcc shrinkdatabase( 
SBSMonitoring, <% free space target>)"). 

4>	If you need more space on your C drive, I would also suggest moving 
available data from your C drive to other partition on your Server. The 
following white paper demonstrates this scenario in detail.

Please refer to Step 5: Move the Monitoring Database in the following white 
Moving Data Folders for Windows Small Business Server 2003

Windows Small Business Server 2003: Windows Vista and Outlook 2007 compatibility update

June 12, 2007

Update for SBS 2003 and Windows Vista using the connectcomputer wizard – link

Remote Web Workplace for SBS2003

April 25, 2007

See: Remote Web Workplace Part 1 (PDF) for more info

Basic Setup:

Configure Internet and Email access settings to allow access to the Remote Web Workplace web service from the Internet (Server Management -> Connect to the Internet -> Web Services Configuration)

Configure the IIS Web application named Remote to Allow access by Default ( ISS Manager -> Web Sites -> Default Web Site -> Remote -> Properties -> Directory Security -> IP address and Domain Name restrictions -> Edit)

Configure the Firewall to allow SSH (Port 443)  to the SBS box from the WAN.  Create a custom service for RWW (Port 4125) and allow access to that service from the WAN to the SBS box.

Connecting client machines must be Windows XP Pro or better

Access the site to test:
From the LAN  https://SBSSERVER/Remote
From the WAN:

SBS SP1 download and installation instructions

April 23, 2007

Link from Microsoft Website

Password Policies can only be Applied to a Domain.

April 6, 2007

Password policies can only be applied to domains and not to individual OUs in Server 2000/2003.  The article below explains why (see the section entitled “Establishing Local Security Accounts Manager (SAM) Password Policies”):  

Some good news is that Longhorn will change this limitation.