Microsoft KB Archive/894632

= E-mail notifications are not sent by SharePoint Portal Server 2003 or by Windows SharePoint Services when content on the portal site or content on the Web site changes =

Article ID: 894632

Article Last Modified on 3/19/2005

-

APPLIES TO


 * Microsoft Office SharePoint Portal Server 2003

-





SUMMARY
''This article discusses an issue in Microsoft Office SharePoint Portal Server 2003 and in Microsoft Windows SharePoint Services where users do not receive an e-mail that notifies them that content on the portal site or content on the Windows SharePoint Services Web site has changed. Users receive an e-mail that notifies them that they have been added to the portal site, but when users add an alert for an item, users do not receive an e-mail that notifies them that the item has changed. This article discusses two causes of this issue and it contains information about the methods that you can use to resolve this issue.''



SYMPTOMS
SharePoint Portal Server 2003 sends an e-mail to notify users that they have been added to the portal site. However, when users add an alert for an item, SharePoint Portal Server 2003 and Windows SharePoint Services do not send an e-mail to notify users that the item has changed. Additionally, an error message is logged to the SharePoint Portal Server 2003 log.

You experience the following symptoms:  You add a user to the portal site in SharePoint Portal Server 2003, and you click to select the Send the following e-mail to let these users know they've been added check box. As expected, the user receives an e-mail to notify the user that they have been added to the portal site. You configure the Alerts feature to send users an e-mail notification when content on the portal site or content on the Windows SharePoint Services Web site changes. However, if users add an alert for an item, users do not receive an e-mail to notify them when that item changes. An error message that is similar to the following is logged to the SharePoint Portal Server 2003 notification log file:

Microsoft.SharePoint.Portal.Alerts.SecurityAccessCheckFailedException: Tripoli Security trimmer failed and returned a null array





Cause 1
This issue occurs if the user account that the SharePoint Portal Alert service is configured to log on as does not have sufficient permissions to read the token-groups-global-and-universal (TGGAU) attribute of user accounts in Active Directory directory service. SharePoint Portal Server 2003 verifies that users have permissions to access an item before SharePoint Portal Server 2003 sends an alert for that item. When SharePoint Portal Server 2003 verifies users' permissions, SharePoint Portal Server 2003 requires access to the TGGAU attribute of user accounts.

Cause 2
This issue occurs if the following conditions are true:
 * You change the user account that is configured as the application pool identity for the administration and content virtual servers in Microsoft Windows SharePoint Services.
 * You do not synchronize the Windows SharePoint Services Timer Service with the new user account information.



RESOLUTION
To resolve this issue, use one of the following resolutions, depending on your situation:

Resolution 1 for Cause 1
To resolve this issue, determine the domain functional level of the domain and configure the Active Directory Computers and Users tool to display advanced features. After you do this, follow the steps in Method 1. If the steps in Method 1 do not resolve the issue, follow the steps in Method 2.

To determine the domain functional level of the domain and to configure the Active Directory Computers and Users tool to display advanced features, follow these steps:  Start the Active Directory Computers and Users tool. Determine the domain functional level. To do this: <ol style="list-style-type: lower-alpha;"> Right-click   in the left pane, and then click Properties.</li> Click the General tab, and then make a note of the domain functional level. If you are running Microsoft Windows Server 2003, the domain functional level is displayed under Domain functional level. If you are running Microsoft Windows 2000 Server, the domain functional level is displayed under Domain operation mode.</li> Click Cancel.</li></ol> </li> Configure the Active Directory Users and Computers tool to display advanced features. To do this: <ol style="list-style-type: lower-alpha;"> Expand   in the left pane.</li> Click Advanced Features on the View menu.</li></ol> </li> Follow the steps in Method 1. If the steps in Method 1 do not resolve the issue, follow the steps in Method 2.</li></ol>

Method 1: Assign the SharePoint Portal Alert service account Read permission to the TGGAU attribute in Active Directory
Assign the SharePoint Portal Alert service account Read permission to the TGGAU attribute on all user account objects and on all group account objects in the domain. The SharePoint Portal Alert service account is the user account that the SharePoint Portal Alert service is configured to log on as. To do this, use one of the following methods depending on whether you have a Windows 2000 domain or a Windows Server 2003 domain.  In a Windows 2000 domain

If the domain is in pre-Windows 2000 compatibility access mode, the Everyone group has Read permission to the TGGAU attribute for all user account objects and for all computer account objects. Therefore, the user account that the SharePoint Portal Alert service is configured to log on as has access to the TGGAU attribute on the user account that created the e-mail notification.

If the domain is not in pre-Windows 2000 compatibility access mode, you must assign Read permission to the user account that is used to run the SharePoint Portal Alert service so that it can read the TGGAU attribute on the user account that created the e-mail notification. To do this, create a domain local group that simulates the pre-Windows 2000 compatibility group, add the SharePoint Portal Alert service account to this group, and then assign Read permissions to the group on all user objects. To do this, follow these steps: <ol> Create a group named &quot;MyAuthZGrp,&quot; and then add the SharePoint Portal Alert service account to the group. To do this: <ol style="list-style-type: lower-alpha;"> Start the Active Directory Users and Computers tool.</li> Expand   in the left pane.</li> Right-click Users, point to New, and then click Group.</li> Type MyAuthZGrp in the Group name box, click Domain local under Group scope, and then click OK.</li> Double-click MyAuthZGrp in the right pane, and then click the Members tab.</li> <li>Click Add.</li> <li>In the Select Users, Computers, or Groups dialog box, type the SharePoint Portal Alert service account in the Enter the object names to select box, click Check Names, and then click OK.</li></ol> </li> <li>Assign Read permissions to the &quot;MyAuthZGrp&quot; group. To do this: <ol style="list-style-type: lower-alpha;"> <li>Right-click Users in the left pane, and then click Properties.</li> <li>Click the Security tab, and then click Add.</li> <li>In the Select Users, Computers, or Groups dialog box, type MyAuthZGrp in the Enter the object names to select box, click Check Names, and then click OK.</li> <li>Click MyAuthZGrp in the Group or user names list if it is not already selected.</li> <li>Click to select the Allow check box that is next to the Read permission in the Permissions for MyAuthZGrp list, and then click OK.</li></ol> </li></ol> </li> <li>In a Windows Server 2003 domain

If the domain is in pre-Windows 2000 compatibility access mode, the Everyone group has Read permission to the TGGAU attribute for all user account objects and for all computer account objects. Therefore, the user account that the SharePoint Portal Alert service is configured to log on as has access to the TGGAU attribute on the user account that created the e-mail notification.

If the domain is not in pre-Windows 2000 compatibility access mode, add the SharePoint Portal Alert service account to the Windows Authorization Access Group (WAA group). By default, the WAA group has Read permission to the TGGAU attribute on user account objects and on computer account objects when Windows Server 2003 is installed. Therefore, after you add the SharePoint Portal Alert service account to the WAA group, the user account that the SharePoint Portal Alert service is configured to log on as has Read access to the TGGAU attribute on the user account that created the e-mail notification.

To add the SharePoint Portal Alert service account to the WAA group in Windows Server 2003, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>Start the Active Directory Users and Computers tool.</li> <li>Expand   in the left pane, and then expand Users.</li> <li>Right-click the user account who the SharePoint Portal Alert service is configured to log on as, and then click Properties.</li> <li>Click the Member Of tab.</li> <li>Click Add.</li> <li>In the Select Users, Computers, or Groups dialog box, type Windows Authorization Access Group in the Enter the object names to select box, click Check Names, and then click OK two times.</li></ol> </li></ul>

Method 2: Assign the SharePoint Portal Alert service account Read permission to the TGGAU attribute on the user account that created the e-mail notification
If Method 1 does not resolve this issue, assign the SharePoint Portal Alert service account Read permission to the TGGAU attribute on the user account that created the e-mail notification. For example, if the user account that created the e-mail notification is a member of the Enterprise Admins group on the domain, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>Start the Active Directory Users and Computers tool.</li> <li>Expand   in the left pane, and then expand Users.</li> <li>Right-click Enterprise Admins, and then click Properties.</li> <li>Click the Members tab, and then click Add.</li> <li>In the Select Users, Computers, or Groups dialog box, type the SharePoint Portal Alert service account in the Enter the object names to select box, click Check Names, and then click OK.</li> <li>Right-click the user account that created the e-mail notification, and then click Properties.</li> <li>Verify that the Enterprise Admins group has Read permission to the user account.</li></ol>

Resolution 2 for Cause 2
To resolve this issue, synchronize the Windows SharePoint Services Timer Service with the new user account information. To do this, follow these steps:
 * 1) Start SharePoint Central Administration.
 * 2) In the left pane, click Windows SharePoint Services.
 * 3) Under Server Configuration on the Windows SharePoint Services Central Administration page, click Configure virtual server for central administration.
 * 4) On the Configure Administrative Virtual Server page, click Use an existing application pool, and then click OK.

<div class="moreinformation_section">

MORE INFORMATION
For more information about the TGGAU attribute, click the following article number to view the article in the Microsoft Knowledge Base:

331951 Some applications and APIs require access to authorization information on account objects

For more information about how to troubleshoot a similar issue, click the following article number to view the article in the Microsoft Knowledge Base:

842423 A call to the AuthzInitializeContextFromSid API function may fail during the delivery of an e-mail subscription

For additional information about how to change the application pool identity for the administration and content virtual servers in Windows SharePoint Services, click the following article number to view the article in the Microsoft Knowledge Base:

832770 How to change the application pool identity for Windows SharePoint Services administration and content virtual servers

For more information about how to configure and administer SharePoint Portal Server 2003, see the. The  (Administrator's Help.chm) is located in the Docs folder in the root folder of the SharePoint Portal Server 2003 CD.

Additional query words: sps wss tokenGroupsGlobalAndUniversal

Keywords: kberrmsg kbtshoot kbprb kbconfig KB894632

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.