Confessions of a SharePoint Consultant

Thought I’d put this out since although there are many posts on this over the Internet I have not found a good example. Knowledge about AAMs are important for any SharePoint administrator

First read this

http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx 

If all that is to hard to digest and all you have is two servers and one load balancer and you feel that your existance would be justified if people could type in www.iamconfused.com (I made that up) and access the site by hitting one of the two servers that are load balanced then read on.

Here is the scenario.

• You have two servers Server1 and Server2.
• Your load balancer is set up such that if someone accesses http://www.iamconfused.com  (I made that up) it will redirect to either http://server1 or http://server2.
• You feel that your existence would be justified if people could type in www.iamconfused.com  and access the site you have designed

First I assume that the load balancer is all set up fine (meaning it works). Get your network admin to verify that.

Browse to the Central Admin. Create your webapp on a port other than 80 (Lets say 1234).

Next extend your webapplication to Port 80 and select the zone as Internet. After this is done make sure that all web.config changes and dlls in the bin folder are moved across to the new webapplication folder.

Once this is done ensure that the application is working as expected on port 80 of the machine you are working on meaning if you  type in http://server1 the site loads up fine. Assuming server1 was where central admin is hosted on. If now you type in http://server2 it might redirect back to http://server1 but that’s OK.

Get to the AAM settings page and select http://server1:1234as the webapp

This should be what you see

Use the Edit public url and Add internal URL links to change this to

I am too lazy to walk through how to get it like this, however its not too difficult.

And thats all there is to it. Your site will be working fine. Just give it a few minutes; I have noticed even after doing an IIS reset the changes take a bit to come into effect.

BTW If you have not got your AAMs configured correctly, and you browse to http://www.iamconfused.com you might see some links in the page pointing to the server name. If you are behind a firewall which only allows access to the  http://www.iamconfused.com this is one reason why you could get a lot of broken links in the site.

With MOSS it is not uncommon for people to have doubts on how to structure sites since there are multiple options and each one offers flexibility in terms of managing different sets of permissions, UI customization etc. Here are my thoughts on this subject.

Lets assume we need a site and start off with a webapplication and a top level site collection. To hold related or detailed information of whats in the top level, I would go ahead and create subsites. Now lets say there is some unrelated info which I need to present. I would look for a different web application if

• I need to specify different permission levels for the site (not permissions)
• I need to have customized web-parts  that I would not like to be exposed in my current site
• Changes or maintenance in the new site should not affect other sites (recycle app pool, change web.config parameters etc)
• Different storage capabilites need to be defined for the new site (Recycle bin size, Max No of users, upload capacity etc)
• I want to use a different authentication provider
• Be able to give site collection owners ability to specify if the site can have anonymous users and my initial site does not allow that ; or the other way around
• Start from a different root level as compared to my original site

One point to consider here is that each web applications have associated default jobs with them that run on a schedule and also each app pool consumes a bit of memory. I really would not go for a different web app unless I really needed it.

If none of the above are satisfied then I would look for a different site collection if I need to

• Use variations and set it up differently from my original site
• Have different set of policies eg expiration, auditing etc.
• Have the sites managed by totally two different sets of users but does not fall into the category requiring different webapps

 Everywhere else just having different subsites looks like a good option.

This is not a hard and fast checklist but some things that need to be considered for deciding the site hierarchy.

Jeremy Jameson has published a blog with some pretty distrubing info on issues with MOSS variations. Surprised to find it published in the MSDN site.

There are certain things that you would wish that MOSS could do and we get a thought;”… if only it could do just this as well….”
One instance I had seen of this is regarding publishing pages all getting into the same folder called “Pages” and no where else. Let say I wanted to create news pages and I wanted to classify them into Local News and International news. Now what I would like to do is have two folders under the pages document lib and while publishing a page having an option to choose which folder to put the page into. Alternatively allow me to put the different pages in different doc libraries. This however is not possible and all I can do is create two different sites one for Local News and another for International news. I could have a field which the user would have to choose what the news type is, however a user in the International news section would expect his info to be added directly to the International news section and would mentally curse all developers were if he had to choose the news type while adding.
I am not too fond of creating too many sites; and in this case its like using a site as a folder rather than anything else; since all my International and Local news sites would contain are the pages.

 BTW, I tried creating subfolders under the pages doc lib and after creating a page, moved it to the directory. It worked fine; except when I tried on clicking the page settings button of the page when in edit mode, I get a message stating that the page cannot be found. All other operations seem to work. I am planning to raise this to MS shortly.

Ideas anyone?

We had a requirement for which we needed to hook up an alert with the document library that would fire at some point in time. The scenario was to have a capability to have a repository in which contracts could be stored and mails sent out to the contract management group a month or so before the contract expires. This scenario should also accommodate for open ended contracts that are basically created one time but gets auto renewed every year until someone decides to stop the contract.
We decided to handle this making use of the expiry policy features in MOSS. So we went and created a documet library that had fields start date, end date and Auto Upgrade which was a choice field (Yes/No) and decided to fire up a workflow one month before the end date that would send off an email to a set of users informing them that the contract was about to expire. The workflow would update the start and end date in case the Auto Upgrade option was set to yes.
MOSS only allows us to define the retention period as a date field + a period.  There is no option to specify EndDate – 1 month (Before you ask, MOSS does not allow you to give a negative number in the period field) . So that would be OK if all my contracts were of a fixed duration, however that was not what we had. There was an option to set the expiration date programatically and it gave in brackets by a workflow. Switching over to SharePoint designer workflow I looked for a field called expiration date, however it was not present. So we wrote a event and hooked it up with the document library to update the expiration date once a document was uploaded. We then created the workflow in SharePoint Designer so that the user could add in stuff without calling for us. One additional step we had to do was to  create a custom activity to update the expiration date for the auto upgrade case since the field is not present in Designer

Recently I came accross a instance where the user did not want to see the View All Site content link above the quick links. Can’t blame him. After making the UI look as business friendly as possible, clicking on the View All Site Content would spit out a list of document libraries and lists categorized according to the technical implementation, very useful for a site administrator, but making no sense to the average business user.

So I decided to put in a bit of security trimming in the masterpage. By default the View All Site Content link is within the tag <Sharepoint:SPSecurityTrimmedControl runat=”server” PermissionsString=”ViewFormPages”> meaning that as long as Tom Jones has the permission to view form pages, he would he would view this link.  Changing the PermissionString attribute to ManageWeb solved this problem, thus making sure that only the Admin could see this.

So what are the other valid options for PermissionString? Here they are thanks to Zac Smith who got them out from a reflected SharePoint DLL

List Permissions
ManageLists
CancelCheckout
AddListItems
EditListItems
DeleteListItems
ViewListItems
ApproveItems
OpenItems
ViewVersions
DeleteVersions
CreateAlerts
ViewFormPages

Site Permissions
ManagePermissions
ViewUsageData
ManageSubwebs
ManageWeb
AddAndCustomizePages
ApplyThemeAndBorder
ApplyStyleSheets
CreateGroups
BrowseDirectories
CreateSSCSite
ViewPages
EnumeratePermissions
BrowseUserInfo
ManageAlerts
UseRemoteAPIs
UseClientIntegration
Open
EditMyUserInfo

Personal Permissions
ManagePersonalViews
AddDelPrivateWebParts
UpdatePersonalWebParts

So how do I determine which groups have these permissions? Simple; Go to Site Permissions and on the settings button select permission levels

Select on the group for which you want to check the permission level and there it is.

This seems to be long over due. After all reading the hype that MS puts around BDC its a disappointment once a person tries to implement it and realize that he would have to write out a huge XML file to get it working. Not very nice.
One had to rely on a third party tool called BDC Meta Man to help generate the file, which was a tad bit expensive for the professional version $1200.Now the latest version of MOSS SDK comes with a BDC Definition editor tool. More details here. Wonder what BDC Meta Man will do now? Slash prices and improve features? Or throw down the towel and fade into oblivion.

Can’t wait to check out the new BDC tool.