Tony Testa posted on July 25, 2008 03:06

Instead of making up an individual post for each of these links and just copying and pasting what the link has, I'm just going to post a big link posting here with a description of each link.  If you can't tell by the links, I was doing some browsing on MSDN :-)  I don't think that anyone can possibly know everything about SharePoint but my general philosophy is to at least be knowledgeable enough to know where to look to find what you need without wasting too much time, so hopefully these links help with that.


Introduction to SharePoint Products and Technologies for the Professional .NET Developer

Whether your new or old to SharePoint this link is a great intro/refresher for SharePoint.  It details what is included in WSS and what is in MOSS (always a common question) along with some nice visuals which can come in handy later.  The part I found to be the most interesting was the terminology section.  SharePoint has a lot of new vocab that can be a bit confusing at first, and for a new developer or BA, this section can be very helpful so that you don't look at people with a blank stare when they throw out one of these terms.


Understanding the Report Center and Dashboards in SharePoint Server 2007

Other than the MOSS Admin test I took a few months back, I haven't worked/looked at Reporting and Dashboards in SharePoint, I just haven't had a need/time to do so.  This link gives you a nice overview of the report center and dashboards as they relate to SharePoint.  It is a good read for anyone that isn't familiar with reporting and dashboards in SharePoint and can quickly get you up to speed with the technology/terms used so that you can get a better understanding in minimal time.


User permissions and permission levels

This link gives a great overview of all the different permission levels in SharePoint.  It also goes down to the list and site level permissions that can be applied as well as descriptions of each.  If for example you were wondering what giving a user "View Usage Data" means, what it depends on, and what level includes it by default then this link is for you.


Back up and restore the entire farm (Windows SharePoint Services 3.0 technology)

The title is a bit deceiving because all of it relates to really WSS 3.0 and MOSS 2007, so the info can be used for both.  What the link gets you to though is a splash page of sorts with links giving you information on how to backup and restore various objects in your farm, even your entire farm.  All this information is good info for any SharePoint "worker" (for lack of a better word, basically anyone that uses SharePoint) because at some point or another,  your going to have to backup an object in SharePoint and this link will give you the info and tools to do so.


Understanding the Administrative Object Model of Windows SharePoint Services 3.0

If you've attended any of my presentations lately, you'll surely know that I am a BIG fan of the SharePoint object model and use it over the GUI whenever possible.  This link goes into even more detail than I have in my past presentations, as well as having some very nice visuals to help put it all together.  What was really helpful to me (and something I gloss over in my presentations) is the difference between the web services and windows services as they relate to a farm.  When I hear "web services" I naturally think .asmx files, but in terms of a SharePoint farm, web services relate to the service that actually serves up the data and web content to the browser.  In addition, it contains a nice code sample at the bottom that iterates over your farm and shows you a lot of info that your probably not used to seeing.


Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

If you've ever created a solution/feature, then you'll know that frankly its a manual and tedious process to get to the actual .WSP file that you want.  Dealing with the .ddf file which is used to make a cab file is a pain, once you know it it's not that bad, but its tedious like I said.  In this link, Andrew Connell does a nice job of showing you how to automate this process by using MSBuild (another tool I have on my TODO list).


Deploy using DBA-created databases (Office SharePoint Server)

Most companies have a DBA and therefore SQL Server falls under their domain.  SharePoint is so database dependant that you'll most likely have to deal with the DBA and they will typically want control of the database that SharePoint users.  If you run into this case then the this link will help you out when the DBA wants control of the databases and creating them.  It also details some of the account permissions that relate to the database accounts for SharePoint.


Database types and descriptions (Office SharePoint Server)

This is a really good link if you want more information as to the databases that SharePoint creates and what they are used for.


Features included in Office SharePoint Server 2007

I finally stumbled on the link I've been looking for for awhile, a list of features that are out of the box with SharePoint.  It goes into detail about what features are activated when you select a site template.  I don't what else to say about this link other than go now, read it and bookmark it, cause i'm sure you'll be going back to it frequently.


Account permissions and security settings (Office SharePoint Server)

Its not new information that SharePoint requires a lot of accounts to run properly.  Each of these accounts has various permission levels and access rights and this link really goes into the nitty gritty details of these.  Another nice tidbit in the link is that it lists some of the file directories and registry keys that SharePoint users and the permissions that they need to function properly.

Posted in:   Tags:

I ran across a really helpful link the other day for a common SharePoint development task...deleting all items from a SharePoint list.  You can read the full article here, as well as the full code over on MSDN Code Gallery

As the posting states, the advantage of the method below is that you pass an XML string batch to the site to have the items deleted, essentially making only 1 connection the server.  Iterating over each list item and deleting them individually would essentially make calls to the server on every delete.

For the sake of this blog posting/historical purposes, I've included the code below to help explain it.


   1:  StringBuilder sbDelete = new StringBuilder();
   3:  sbDelete.Append("<?xml version=\"1.0\" encoding=\"UTF-8\"?><Batch>");
   5:  string command = "<Method><SetList Scope=\"Request\">" + spList.ID + 
   6:  "</SetList><SetVar Name=\"ID\">{0}</SetVar><SetVar Name=\"Cmd\">Delete</SetVar></Method>";
   8:  foreach (SPListItem item in spList.Items)
   9:  {
  10:      sbDelete.Append(string.Format(command, item.ID.ToString()));
  11:  }
  13:  sbDelete.Append("</Batch>");
  15:  spSite.RootWeb.ProcessBatchData(sbDelete.ToString());


What I really like about this code is its simplicity, but also provides the ability to do some add conditions inside the foreach loop, and test for certain values.  This way, you could delete say, all items with a date of 1/1/2007. 

A few things to note after reading the posting and its comments.

All items that get deleted from this method go into the Recycle Bin which is important to remember.  To COMPLETELY get rid of the items, use the code above then also call the delete method of the Recycle Bin from your SPWeb object ( mySpWeb.RecycleBin.DeleteAll(); )

Another option, which is a tad less flexible, but does essentially the same, is to switch a list to data view mode, which turns it into an excel like spreadsheet where you can highlight all the rows and delete them that way.


Needless to say, the options above are better then just iterating through all the items in the list and calling delete.

Posted in: Sharepoint  Tags: ,
Tony Testa posted on July 20, 2008 16:13

I lack serious knowledge about Workflows when it comes to SharePoint.  I've worked with them briefly, but not nearly as much as I should have.  Recently I was asked a pretty basic SharePoint workflow question which forced me to find out what workflows come out of the box with SharePoint.  Here is a listing of the out of the box SharePoint workflows taken from the SharePoint Team Blog.

Approval Routes a document for approval. Approvers can approve or reject the document, reassign the approval task, or request changes to the document.
Collect Feedback Routes a document for review. Reviewers can provide feedback, which is compiled and sent to the document owner when the workflow has completed.
Collect Signatures Gathers signatures needed to complete an Office document. This workflow can be started only from within an Office client.
Disposition Approval Manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents.
Group Approval Similar to the Approval workflow, but uses a designated document library and offers a personalized view of the approval process(es) in which a user is participating. This workflow provides a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution was designed specifically for East Asian Markets.
Translation Management Manages document translation by creating copies of the document to be translated and assigning translation tasks to translators.
Issue Tracking Manages the issue tracking process by creating tasks for Active issues assigned to users who own to a given issue. When the task related to an issue is complete hence resolving the issue, the creator of the issue is assigned a review task so that the issue can be closed.

Posted in: Sharepoint  Tags: ,

Recently a colleague of mine was dealing with a client whom he had been building an FBA site for.  All was fine and dandy until it came time to deploy the FBA site to the clients production WSS v3 server.  It turns out, which was completely news to me, that WSS v3 during the installation allows Active Directory Account Creation Mode to be enabled in the advanced settings.  I lended a hand and as you'll see why below, I immediately regretted the decision.

Ok you say, that's nice, WSS v3 allows that setting but the bad news is that apparently ADAM and FBA do not play nice together.  When WSS v3 is installed with the ADAM setting enabled, it makes the assumption that account names are in the form "domain\username".  Now anyone that has dealt with FBA knows that FBA account names are in the form "membershipProvider:accountname", so you can immediately see the problem.

ADAM and FBA just won't work together as it turns out, so after some digging, a BA I work with ran across the following link (  The link is to a document which details best practices for setting up WSS v3 in a Shared Hosting Solution.  Page 13, section 3.1.1 details Account Creation Mode, as well as page 16, section 4.1.1 details its shortcomings.  Page 23, section 5.1.1 details how ADAM and FBA just won't play nice together.  The key section in the document is 4.1.1.  That section states that MS recommends that you move off of ADAM at your earliest convenience, as well as stating that its a deprecated feature in WSS v3 and really shouldn't be used.  The document also states that ADAM is a security risk but doesn't really state why.  I also found (, I believe it was Mike Walsh (a WSS MVP) stated that the next release of WSS will not support ADAM, that alone should prove why not to use it.  One final shortcoming I was able to dig up was that MOSS 2007 doesn't support ADAM, which should be another indicator to you why not to use ADAM.

Alright, all the above being said, we needed to let the client know exactly what security issues there were with having ADAM enabled.   Below is what I received back from a source at Microsoft:

  • When we use Active Directory account creation mode ,We have to use command line tool for creation of sites and other admin related tasks.
  • Limited user creation capability.
  • Users cannot be created in different OUs.
  • When we use Active Directory account creation mode, we cannot use pre-existing domain accounts; instead, new accounts are created whenever we add users.
  • Creating users and cross-site groups with Active Directory account creation mode is the same as creating users with domain account mode, except that we only enter the e-mail address or group name, not a domain account, when adding the user or cross-site group to a site. Windows SharePoint Services checks Active Directory to see if an account with that e-mail address or group name already exists. If the user or cross-site group already has an account in Active Directory, the account is used. If the user or cross-site group is new, an account is created for them in Active Directory, using the Windows SharePoint Services credentials, and they are notified of their account name and password through e-mail. This is very risky.
  • When we are in Active Directory account creation mode, there are certain administrative tasks that are unavailable in the HTML Administration pages. For example, we cannot create a top-level Web site, we cannot enable Self-Service Site Creation, and we cannot add a user to a site from the Central Administration pages. To perform these actions in Active Directory account creation mode, we must use the command line or the object model.
  • When we create a new account with Active Directory account creation mode ,The Minimum Password Age group policy on the domain controller must be set to 0 days. Failure to do so will result in users being unable to change their passwords, unless they have administrator rights on the server.
  • The ADAM authentication mechanism uses accounts defined within its own data store, Windows accounts valid on a system on which an ADAM instance instance resides, or it can redirect authentication request to Active Directory or Windows NT domains. In the latter case, the link to the Active Directory account is based on having its SID value stored in an ADAM user Proxy object. Redirection via proxy not only provides a single sign-on, but also enables storage of application-specific data for an Active Directory user outside of the Active Directory database, which is very problematic.
  • No administrator friendly account management Directory Services tool (equivalent to Active Directory Users and Computers) is currently available for ADAM installations. SO administrators will have to resort to more challenging methods to populate and manage directory information.

This basically answered well enough for me the security issues revolving around using ADAM.

Below are also some good links that may come in handy for you as well if you run into the issue.


Long story short, ADAM is deprecated in WSS v3 and will not be support in the next version, ADAM and FBA don't play nice so move off of it ASAP to avoid issues for  yourself in the future.  If your working with MOSS, then you need not worry since ADAM isn't even an install option, so no chance of accidentally turning it on.


Originally we stumbled upon this problem when doing a site collection backup to the WSS v3.  The GUI threw us an error so we tried STSADM but still no luck.  The following links provied useful:

Posted in: Sharepoint  Tags: , ,
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Tony Testa's World