Sandoval's SharePoint Spot

See solution here:

http://rehmangul.sauftveyr.com/2008/04/23/can-not-add-the-user-because-a-user-with-that-name-already-exists/

Worked for me.

Thanks to Rob Fisch at LinkedIN.

It’s true. Even with WSS2 (Sharepoint 2003) and Outlook 2003 there was an ability to view SharePoint calendars, right from Outlook. But there was no way to overlay the information together all in one calendar view. With WSS3 (or MOSS 2007) and Outlook 2007, we have the ability to not only view activity from multiple calendar sources in one virtual calendar view, but we can also edit these SharePoint calendars directly from Outlook. We can also tack on Outlook reminders to SharePoint Calendar events.

Read the full article:

http://www.mssharepointtips.com/tip.asp?id=927

Important things too know about using TODAY in a calculated column!

http://www.linkedin.com/news?viewArticle=&articleID=185992482&gid=93094&type=member&item=28659782&articleURL=http%3A%2F%2Fblog%2Epentalogic%2Enet%2F2010%2F09%2Ftoday-sharepoint-calculated-default-values%2F&urlhash=q1qF&goback=%2Egde_93094_member_28659782

A life saver of an article from Ben.  I used these steps to recreate the default dispform.aspx page!

You need to edit a line of code in SharePoint Designer

• Go to Code View
• FIND:  “Placeholderleftnavbar”
• Delete Row (approx. line 47) that has that above code
• OK to Change site definition

SSO Single Server Sign On

Add Application Services in Central Admin

1. Operations Tab
2. Manage Settings for SSO

Ensure SSO Service is Running (If you get a “Failed to Connect…”)

1. Start/ Admin Tools/ Services
2. Open Microsoft Single Sign On Services
3. Log On Tab
4. Best Practice to use to Server Admin Account (from A.D.) not the Local System Account
   1. Provide Name Password
5. General Tab
   1. Start Service/ OK

1. Manage Settings for SSO
   1. Manage Server Settings
   2. Provide an SP SSO Admin Account
   3. Provide Enterprise Application Definition Admin Account (usually the same as SSO Admin Account)
   4. Creates a SSO DB (Server Name, DB name)
   5. Click OK
2. Manage Settings for Enterprise Application Definitions (link)
   1. Create a New Item for Each Back end system that will be used to with each application requiring connection.
   2. Display Name for SSO Admin
   3. Application Name that Site Admins will use to connect (No Spaces)
   4. Contact e-mail for back end db
   5. Account Type (best practice GROUP)
   6. Authentication Type (Leave blank so that no authentication is required).  This will allow for the passing of credentials
   7. Create a SP Name and Password for this Application Definition.  Ok to leave defaults (“Username” [mask NO], “Password” [mask YES]).  Not a best practice!
3. Manage Settings for SSO
4. Manage Account Info for Enterprise Application Definitions
   1. Provide account information that is going to be passed.
   2. Pick Enterprise App Definition created in Step 3.
   3. Provide Group name (See step 6 below)
   4. Click SET to provide User Name and Password for Enterprise Application.  (Best Practice to not provide Enterpise App Sys Admin.  Use a Enterpise App Read Only Account),
   5. Click OK/ Done

Active Directory (use to find AD Groups)

1. 1. Start/ Admin Tools/ AD Users and Computers
   2. Get name and verify membership

1. Manage Encryption Key
   1. Click Create Encryption Key
   2. Click OK/ OK

• • NOW TO USE SSO!

1. You will be using the Application Name (not Display Name) to make a connection to the db)

In SP Designer

1. 1. Go to Data View Menu
   2. Click Insert Data View
   3. From Task Pane Connect to a Data Base
   4. Click Configure Database Connection
   5. Server Info is where (SQL Server is running)
   6. Authentication (USE SSO)
   7. Click Settings
   8. Provide Application Name (Step 3c, no spaces) and
      Application Username and Password (Step 3g)
   9. Click Next/ Select Database/ Select Table
   10. Click Finish/ Ok to make the connection

Another GREAT tip from Christophe at Path to SharePoint

=IF([Status]=””,”Black”,IF([Status]=”Choice1?,”Red”,IF([Status]=”Choice2?,”Gold”,IF([Status]=”Choice3?,”Green”,IF([Status]=”Choice4?,”DarkBlue”,IF([Status]=”Choice5?,”DarkCyan”,IF([Status]=”Choice6?,”DarkRed”,IF([Status]=”Choice7?,”Gray”,””))))))))&IF([Status]=”Choice8?,”MediumSlateBlue”,IF([Status]=”Choice9?,”SpringGreen”,IF([Status]=”Choice10?,”MidnightBlue”,IF([Status]=”Choice11?,”Sienna”,IF([Status]=”Choice12?,”SlateGray”,IF([Status]=”Choice13?,”OliveDrab”,IF([Status]=”Choice14?,”Gray”,””)))))))

http://www.5min.com/Video/How-to-Modify-the-Layout-of-a-Defaultaspx-Page-in-MS-SharePoint-Designer-80729198?

Good demo for SPD beginners.

http://www.5min.com/Video/How-to-Customize-List-View-Pages-in-MS-SharePoint-Designer-80729533

Another great solution from Path To SharePoint. This links also includes a screen cast.

The Web Part can be used on a SharePoint 2007 site by anybody who has design or full control permissions (it is actually based on a Content Editor Web Part). The installation does not require server access.

Index Crawl: minimum 15 min.
5,000 sites takes 15 min. to replicate

When you create an SSP you need to create a crawl account
If crawl account is Admin Right, then it will crawl major and minor versions.

stsadm-0 command resets Admin password

Manage File Type to include PDFs

ifilter.org: install on front end server.

Thanks to Rob Fisch on LinkedIN.

With WSS3 (or MOSS 2007) and Outlook 2007, we have the ability to not only view activity from multiple calendar sources in one virtual calendar view, but we can also edit these SharePoint calendars directly from Outlook. We can also tack on Outlook reminders to SharePoint Calendar events.

Read the full article:

http://www.mssharepointtips.com/tip.asp?id=927

See discussion at microsoft.public.sharepoint.portalserver

Solution provided by Dessie Lunsford at EndUserSharePoint.com.

Good question, and more important, great feedback from Jie  Lie.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=14186886&gid=42512&trk=EML_anet_qa_ttle-cThOon0JumNFomgJt7dBpSBA

SharePoint search result is trimmed by permissions – which is working with content sources like SharePoint, File Share and Lotus Notes (if you choose to not ignore security). 

But keep in mind. Security info is picked up at indexing time OOB. So if you changed the permission of a file or folder, the result won’t be changed immediately until the next time it gets crawled (by full or incremental crawl). Custom security trimmer(CST) can help to do another round of realtime security trimming but it has a bad impact on performance.

Workflow History can be found at

/lists/Workflow%20History

Special Character that are reserved and not to be used in creating Folders.

Invalid characters include the following: ~ ” # % & * : < > ? / \ { | }.

Also, the name cannot begin or end with dot and cannot contains consecutive dots.

Solution: STG Print Folder Plus can globally replace characters.  ECHO can also migrate content and replace illegal characters

Published Thursday, September 11, 2008 11:24 PM by erobillard

SharePoint Security: Hard limits and recommended practices

This summarizes the hard limits and recommended guidance for Groups, Access Control Lists (ACLs) and securable objects in SharePoint 2007.

Unique accounts or groups per SharePoint Group: ~2000. This is the identical with the guidance for any large SharePoint list as covered by the Working with large lists in Office SharePoint Server 2007 whitepaper. Lists can handle thousands of items, but performance of a Views (i.e. while viewing or updating membership) will degrade after 200 items and become unacceptable towards 2000 because the underlying SQL queries are not paged or filtered. Note that the next limitation (see Users per SharePoint ACL, below) will affect the ability to index any item (or list) you apply such a large ACL to. Resolution: Use a third-party tool to manage large SharePoint Groups or re-think your design to include AD groups. Mitigation: When possible, rather than assigning users membership in a SharePoint Group, assign users to an AD group and then assign the AD group membership to the SharePoint Group.

Users per SharePoint ACL: Query results must not exceed 64k, or ~1000 users per ACL. When exceeded, the “Parameter is incorrect” error is thrown causing crawling to fail on the item. This issue affects indexing, but does not otherwise affect SharePoint. The limit is noted by Joel Oleson in the comments of a “2003 to 2008 security changes” post and the Best Practices for SharePoint Search article on TechNet. The issue is not SharePoint-specific and will affect any content crawled with large ACLs including file system objects like Network Shares. KB article 885482 describes the cause as “The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB.” Resolution: Either exclude the item from indexed content, or remove entries from the ACL. Mitigation: This is a rare issue normally avoided through sound design. However, since AD groups are not expanded when the ACL is read, assigning individuals to AD Groups rather than SharePoint Groups will mitigate the limit.

Active Directory groups per-user: 1024. Each membership increases a user’s “SID count” and the limit on the token bag is 1024. When the limit is exceeded the error reads, “During a logon attempt, the user’s security context accumulated too many security IDs.” The whitepaper Addressing Problems Due to Access Token Limitation discusses the issue in depth, and KB 906208 describes the error. Consider this limit if AD groups are to be used to manage SharePoint groups. Resolution: Remove the users from one or more AD groups to reduce the SID count. You can verify the issue with the Group Membership Evaluation feature of the Ntdsutil.exe tool. Mitigation: Manage users in SharePoint Groups rather than AD groups if growth would require any user to be a member of more than 1024 groups.

Recommended Guidance
The Plan for Software Boundaries whitepaper contains guidelines for “people objects” but its guidance for security principals is (politely) less-than-useful. For example, the guidance that “You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users” says nothing about how many people can (or should) be added to a SharePoint Group and ignores the SID limits of AD groups. It would also lead you to believe that it’s an acceptable option to use local Windows security groups to manage permissions rather than domain accounts. In a nutshell, that would be a bad idea if your farm will ever have more than one server.

There are many MSDN and TechNet articles with recommendations on what granularity of permissions is “right” but the one simply named Plan site security is the most detailed and provides the best example. To summarize and disambiguate the best practices and recommendations:

1. If many securable objects share the same ACL, then group them into a container with that ACL. This applies equally to list items within lists, or libraries within sites. If the permission change is a temporary state in a securable object’s lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow). [Update 2008-09-12 TB] Avoid unique permissions on folders, as Flat views will not secure folder content as expected.
2. The more ACLs you create, the more ACLs you have to manage. I know, I know, it’s self-evident, no? How I wish it were. A problem of some articles is that they can be interpreted to recommend moving the problem rather than solving it. For example: “Minimize the use of custom or fine-grained permissions. The more fine-grained permissions that are applied, the more difficult it is to track who has access to what.” Well duh. The problem is that not applying permissions does not remove the business need to have permissions. If the issue is the tools and not the limits of the platform, the correct guidance should be “if management or reporting tools don’t work the way you want. . . .” Better, it deserves to be a recommendation of its own.
3. If management or reporting tools don’t work the way you want, then build or buy better management or reporting tools. DeliverPoint is one option. [I'll continue update this post as others are suggested.]
4. Understand the strengths and weaknesses of managing users in SharePoint Groups vs. Active Directory. A strength of SharePoint Groups is allowing the same people responsible for building teams in an enterprise to form their own groups. IT has been the bottleneck for too long. Advantages of SharePoint groups are decentralized maintenance, isolation by Site Collection, the ability to query it with the API without adding to DC load, and the ability to integrate it as necessary with external Authorization Providers (AD, FBA, etc.). This last point makes SharePoint groups preferable for extranets and mixed authentication zones, allowing internal users to authenticate through AD and external users through another AuthZ provider.

   AD Domain Groups may be preferred for central management and a standardization of tools. Unfortunately these tools are not usually built for or available to users outside of IT and support services. AD groups are also not visible from within SharePoint without custom code or third-party components.

   Unless your AD groups are subject to strict discipline so that “Help Desk” only contains people from Help Desk, and not people who for any reason one day needed access to the Help Desk’s files (e.g. senior management or Gladys from accounting), it is best to start fresh with new AD groups for SharePoint. Since 95% of companies did not have that discipline when securing network shares, you should start fresh unless you can both prove that your AD groups are clean, and policies are in place so groups will not be corrupted when people start applying them to SharePoint.

   [Update 2008-09-12: This entire section was rewritten based on TB's suggestions. The earlier version preferred ADGroups to SPGroups solely by virtue of central management.]

5. If you break inheritance on many lists for the same users, clean up duplicate Limited Access entries in the containing site. When you configure a list or list item to use unique permissions and add a user to it who is not listed as a member of the site, so as to not break navigation the user is automagically given Limited Access — bare-minimum read access — to the site that contains the list. All fine and dandy until it hapens again and a duplicate entry is created. Resolution: Remove the duplicate entries by hand or automated utility.
6. Do right for the Business. Sometimes to meet a business need you need to break from the recommended guidance. There is “recommended guidance,” and then there are hard limits imposed by the platform that you should not break without raising flags and shooting off fireworks. The appropriate solution may be at odds with “recommended guidance” and that’s okay. Your goal is to simulate the business, not to change the business. When conflict happens, help the business understand its choices. Make any conflict crystal clear to the people paying the bills and suggest alternatives. If the conflict is a hard platform limit with an eventual breaking point, provide all the options to mitigate the issue and make sure that the person with the power to make the decision understands the eventual consequence of the decision. You cannot stop someone above you in the food chain from blowing his or her own foot off. This is natural selection. You can only prove that you asked them not to, and escalated alerts to the issue as danger became imminent.

Thanks to Dennis Shtemberg from Infusion for getting the ball rolling with his research on uniquely-permissioned items per list, Todd Klindt for a great dialogue, corrections and help to tease apart the issues, Todd Bleeker for taking the time to review this post and make it better, and Joel Oleson and Keith Richie for their clarifying the ACL issue and their earlier work on the subject. Todd and Keith are co-authors of DeliverPoint.

Fixed or Unproved [Last Updated: 2008-09-26]

This section contians the guidance that either no longer applies, or never did.

Unique list-item permissions per list: 600 to 1000. Resolved by WSS and MOSS SP1. When you assign unique permissions to list items in a given list, when the critical point is exceeded the error is displayed: “Operation is not valid due to the current state of the object” and the following event is logged in Event Viewer: “Unknown SQL Exception 156 occured. Additional error information from SQL Server is included below. Incorrect syntax near the keyword ‘SET’. Incorrect syntax near ‘)’. Incorrect syntax near the keyword ‘with’. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon.” Resolution: When any list item with unique permissions is deleted, the list works again. When any list item with inherited permissions is deleted, the issue persists. Mitigation: If many items will share the same ACLs, then group them into a separate list or library and apply the ACL to the list or library. If the permission change is a temporary state in a list item’s lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow).

Users listed in a Site Collection’s User Info Gallery (aka SPWeb.SiteUsers): 1500 to 2000. No evidence can be found to support this guidance, and believe it to be a misinterpretation of the limit on ACL size. If you’ve been affected, please comment with further detail.

A user is added to this list (and assigned an ID unique to the Site Collection) when a user is a) explicitly assigned a permission level on a securable object, or b) when a user is named as a member of either a SharePoint group or an Active Directory (AD) Group and that group is assigned a permission level on a securable object and the user then contributes to the site. Note that prior to WSS 3.0, just visiting a site added the member to the list, and now the user needs to actually contribute. When a user is deleted from the list either through the API or the User Info Gallery, the entry is marked “Deleted” but not removed [Update 2008-09-12: Corrected by KR]. Resolution: If you pass the limit, you need to remove users from the list. The difficulty is figuring out which are no longer listed in Created By and Last Modified By fields. Displaying or editing a list item with a reference to a deleted entry results in an error. Mitigation: 1) Create Site Collections such that each will serve up to 1000 contributors. [Deleted: "Create AD groups for readers." Not necessary as readers aren't added to the list.] Monitor the size of the SiteUsers list, and consider routines to prune rows from it where contributors are no longer named on sites in the collection (e.g. in Created By, Modified By, or Assigned To columns). 2) Either assign AD groups, or a combination of AD groups and individual users (the exceptions who do not logically belong in the AD group) to SharePoint Groups unless this will lead to SID count issues (see Active Directory Groups per User, below).

Published Thursday, September 11, 2008 11:24 PM by erobillard

When editing too many users on a permissions page, it will give a browser error.

Edit in groups of 25 or so…

Append the following text to the URL, directly after “…aspx”

?contents=1

an example would be…

https://gain.paegroup.com/Pages/Default.aspx?contents=1