There is a verry easy way to hide the Quick Launch if you only want to do this on or two pages.

This is how you do:

1. Go to the site or list where you want to hide the Quick Launch.

2. Go to Site Settings and select Edit Page

3. Add a Content Editor Web Part to any of your Web Part Zones (This web part will be hidden so it doesn’t matter where you put it).

4. Make sure that you select the Hidden attribute for the Web Part and the click on Source Editor…

5. A little bit depending on if it’s on a site, what kind of list, theme and if you have any custom styles on your site the below code could change but it will work in most cases and I will describe how you find make it work in case it doesn’t.
Copy the below code and past it in the Source editor

<style>

.ms-pagetitleareaframe
{
display: none;
}
.ms-navframe
{
display: none;
}
.ms-titleareaframe
{
display: none;
}
</style>

6. Click Save and then Ok in the Web Part Settings frame and finally exit the Editing Mode

7. You should now have a page that does not show the Quick Launch and we have done this by overriding the style sheet. If parts of the navigation is still showing you need to override more attributes and to know which ones I recommend you to use the IE Developer Toolbar.

This IE plugin from Microsoft makes it easy to click on an object on a web site and show what attributes or classes it is using. If you are using IE 6 or 7 you can download it from here: http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

And if you are running IE 8 which is default in Windows 7 you have it already built in, how to use it can be found here:
http://msdn.microsoft.com/sv-se/library/dd565628(en-us,VS.85).aspx

Visualize yourself the scenario were you are about to set up a SharePoint environment containing a lot of Web Applications and that some of them needs to be extended both two and three times. Add to that, that you need to set it up in a Test, QA and a production environment and in the same way have a good recovery plan for setting them up again in case of a disaster.

In two earlier posts I have written about how to create a Web Application and how to extend a Web Applicationusing PowerShell. Now it’s time to combine the two into one script where we use a input file as source. In this case I decided to use Excel, so it’s easy to fill in all info on your Web Applications in an Excel file. By using a macro you can then by pushing a button in Excel generate a xml-config and that’s the one to use as input for your PowerShell script.

First, let me introduce the Config Generator. This is an excel file where you fill in the info on the Web Applications that you want to set up. Below is a list of all the settings you fill in, in the Excel sheet. One Web Application or extend of Web Application per row.

As you can see you have a couple of fields related to the IIS Application Pool. What the script does is that, if you have filled in the WebAppUsername the Application Pool will be created with the new credentials. If you leave the WebAppUsername blank it assumes that the Application Pool exist and connects the site to that Application Pool.

You will also find columns to insert Site Collection information. This info will be put into the config file as well and used for creating the root Site Collection of your new Web Application. The following settings are available:

When you have filled in the info on all your Web Applications just push the Generate Config File button and Excel will generate a config.xml file in the same folder as the Excel file is located in.

What you then need to do is to copy the config.xml to the server along with the CreateWebApps.ps1 file.

Open up the PowerShell command shell, include the file CreateWebApps.ps1 file by typing:

. ./CreateWebApps.ps1

Then you call the function by typing:

SP-WebAppBuilder -ConfigPath [path]\config.xml

This will now generate all your Web Applications as you have specified in the Excel-file so go grab yourself some coffee and let the script handle the rest.

The above example is an teaser of what will be covered in the coming book SharePoint and PowerShell – In real life that I together with Niklas Goude is writing. The code can be found in the download section.

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

My first thought was of course that something had changed with the Service Account used for crawling, something that got more obvious since they had almost the same error message in the Event View:

But when we looked at the Service Account everything seemed ok, the account had not been disabled or expired. Then I suddenly got another call from a customer that had the same problem and she also had another very strange problem since she could not access the SSP settings page. Central Administration worked but she got access denied on the SSP.

Two different environments with almost the same problem. This had to be with some updates on the server, right I was. Both machines had automatic Windows Updates and had therefore got an update that caused problems with use of fully qualified domain name (FQDN) when browsing a local site.

There is a solution for this and you find the Microsoft KB here: http://support.microsoft.com/default.aspx/kb/896861

So what have we learned? Well, first of all, never use automatic updates in production environment and always use a test, QA, staging or pre-production (whatever name you choose) to test all new changes. Things can fail even if it’s not a specific SharePoint update.

Search in WSS
I’m not sure that the standard search in WSS is actually allowed to be called search… It’s not very customizable but the good thing here is that Microsoft gives you the Search Server Express for free. This at least gives you quite a lot of extra things to do. For instance Federated search, iFilters, index file shares etc.

http://www.microsoft.com/enterprisesearch/serverproducts/searchserverexpress/default.aspx

MOSS Search
For those of you that installed Moss in its first version know that since the Infrastructure update released almost a year ago it has taken a few steps forward when it know contain all the functionality that is included in Microsoft Search Server. There is however a huge disadvantage (as in the WSS with or without Search Server Express), there is no wild card search. Something that everyone needs to be able to find, well, anything…
But on the other hand, if you can solve that (as I will talk about below) you have quite a lot of options to tweak the search and since the SharePoint Search Results pages are built on publishing sites you have a lot of options to give the users a good search experience.

If your organization use My Sites then you have huge amount of advantages in sharing knowledge finding internal resources etc.

http://www.microsoft.com/enterprisesearch/serverproducts/moss/default.aspx

Dot net mafia wild card search
The Dot net mafia wild card search is a Codeplex project that has been around for a while and now starts to be quite competitive, especially if you have the luck of internal development resources. What this wild card search does is that it actually replaces the standard (well you have to do it yourself) results web part and then displays a wild card search results. It works both for document’s items and for people search.

http://www.codeplex.com/WildcardSearch

Ontolica
Ontolica has a couple of different solutions for SharePoint and they come with different licenses. The basic search they offer is a wild card search that allows you to use “*” in any search webpart you have, it works very well but it’s probably their Ontolica Saerch solution for Moss that is most impressive. This offers a whole new search site template and includes Metadata search, Drill down results and images search. Just such a small thing as to search for people by letters makes it so much easier to work in Moss. (And no, I did not get anything for this…)

http://www.ontolica.com/

Fast
No one has probably missed that Microsoft know owns the Norwegian company Fast that delivers cutting edge search platforms and has been since quite a while be innovators within the field. Already today there are integration possibilities between Moss and Fast and this combination is one discussion for itself. I have not worked with this integration myself, just seen it so if anyone of you has and want to share your knowledge I will be more than happy to listen.
Moving forward with “Office 14″ we will see not one but a couple of steps forward for SharePoint and Search.

http://www.fast.no

Looking forward and looking at the more complex search engines that are still very expensive and mostly targeted for enterprise usage we have only seen the top of the iceberg. After having seen a couple of the cutting edge platforms in action I can’t stop thinking of Metadata and how much we actually will need it. We don’t need metadata? You will say I’m crazy, but the new search engines are so cleaver in indexing the content of the actual files that it will not surprise me if the huge focus on tagging everything with metadata values might decrease. I mean, think about it.
If you have a document with security classification “Internal” attached to it with a Site Column, and then in the actual file it says Security Classification “Secret”, what is most likely the accurate classification? And since the larger Search Engines or platforms can handle this, with language support and then sort it or classify it, don’t you agree just slightly with me?
I however still think that Site Columns and categorization in for instance SharePoint will remain a very important cornerstone of document management. But the usage will probably be more focused on sorting and grouping your documents or list items to present the data in different ways. Not as much as support for the search engine.

Microsoft has a Enterprise Search site where you can compare their own solutions and find more information: http://www.microsoft.com/enterprisesearch/default.aspx

What we will do in the following two posts is that we will create a workflow to automate this process so that the end users can request a site. When the site is approved the site will automatically be created.

In our case we will as in earlier post use the Site Directory in MOSS but you could easily change this to be any kind of list in either MOSS or WSS.

Below is a picture of the Site Directory. The only thing we have added is Type of Site, this will be used later to know what template to use in the site creation process. What we then do is that we allow users to create entries in the list and as default the Site Directory has the content approval turned on. If you don’t use the Site Directory you can turn on the Content Approval in List Settings and Versioning Settings.

When we have added all the fields we need in the Site Directory the end user can go to the form and fill in the information about the site they want to have.

And when the item is added, the Approval Status will be saying pending. Now it’s time for the administrator or the owner of the collaboration area to approve or decline the request. He or she also has the possibility to add or change some of the information if the request does not follow the policy in naming standards etc.

What we also need to do is to have a PowerShell script that is set up as a timer job and that with your chosen frequency looks in the list and sees if there are any items that has an Approval Status = Approved and no Created Date. If it finds any entries matching the criteria it takes the information from the list and creates the site.

Curious about how the script is done? Niklas will not disappoint you, part 2.

The Site Hierarchy simply shows a list of all sites in the Site Collection with URL, Title and a link to their respectively Site Settings page.

From this page you could do a copy and paste in to Excel and then from there do whatever you want do with the information; count the sites, or use it as a base for your inventory.

The other option, the Site Content and Structure page gives you a little bit more information like, last modified and who has created the site but on the other hand, you will not be able to generate any report and there is no good way to copy the information and past to Excel.

There are a couple of 3de party products out there that could help you with generating such a report and in addition you often get other various statistics such as size, created date, owner etc.

But there are other ways to do this that is more customizable and best of all, it’s free! It is possible with PowerShell to loop through all sites in a Site Collection and then easy export it to a CSV file to open up in Excel. In this script we will extract the following information:

Name
Title
Description
Theme
WebTemplate
Author
Created
Modified
Sites
Users
ParentWeb
Url
ServerRelativeUrl
ID

But more information is available and it should also be mentioned that the loop is useful in many other scenarios were you want to perform the same task on all your sites. For instance you could use it in our previous post where we removed old users from a site (found here). So, let’s take a look at the script and get an explanation of how it’s done and what it does. Read part 2 at www.powershell.nu

If you want to download the script you find it on the downloads section

The picture below shows how it looks with custom fields in the Create New Site page.

What also happens automatically is that all the choice fields will be listed as links were you by clicking on them get a search result with all the, in this case customers. But unfortunately this only happens if the field is a choice field added to the list, not even if you have a Site Column or Lookup field it shows up on your Site Directory page. You might also in some cases avoid having choice fields directly on the Sites list because in the name changes, it will not change on all sites automatically. In that case you need to have a lookup field, and as mentioned that does not automatically appear on the Site Directory page. So what if you want to have your other fields searchable in the same way? Well, it’s possible with some good old html.

Below you see that we only have the two choice fields to choose between.

But before we create our custom category with links, let us analyze what happens when clicking on any of the existing categories. The page that the link takes us to is the categoryresults.aspx located in the Pages directory. So let take a look at the querystring:

categoryresults.aspx?Column=DivisionMulti&ColumnDisplayName=Division&Value=IT%20Services

The querystring field Column is the column that SharePoint will search in, and what you need to know is that it’s the columns internal name and not the display name that needs to be put in here. So if you have create a lookup field named Service you just change the “DivistionMulti” to Services. The next querystring value is the display name, and in this case that means that it’s simply that value that will be printed out on the page to show the end user what they search for. And in the last querystring value, named Value you type the value you want to search on.

The final result will look like this:

categoryresults.aspx?Column=Service&ColumnDisplayName=Service&Value=SomeService

So, let’s go to the Site Directory page, select Edit page from the Site Actions drop down and add a new Content Editor Web Part. Now, it’s all up to you to populate and to style it your way. If you want (and why shouldn’t you?) to have the same style, take view source on the page and you will find the right style classes used.

Yes, this will make you have to manually update the categories if they change but, by experience they don’t change that often and this is a quite solution that don’t involve any custom web parts.

Below you see the final result and one screenshot on the page in edit mode.

As you might know this is not done automatically and it’s not possible with any standard out-of-the-Box feature in either WSS or Moss but it can be accomplished with PowerShell. The script, which will be described in more detail by Niklas Goude, simply removes the user from the site. This can of course be modified so that i loops through the site collection, but hang on, we will soon update this script with more goodies.

If you are using Moss, you should keep the employees User Profile and My Site, because if you remove the User Profile you will get problems with references pointing to that user e.g. in the Created By field.

What you can do in the My Site to not confuse your users (or if you’re in a larger company where not everyone gets informed when someone quits) is to have a custom Property displaying the employment status.

Now it’s time to check out the script and move over to part 2 at www.powershell.nu. If you want to download it right away you find it on my download section.
This is the second cross-posting together with Niklas Goude, if you missed the first one about how to batch create sites you find the article here.

Let’s start off with the scenario. You are about to move a large amount of customer data in to your MOSS environment. To structure it you have decided to create a site for each customer and store all relevant information about the customer in each site. The problem you face is that in SAP you currently having 700+ customers and if you should create all of them one by one, you will probably need to pass the task on to your grandchildren before it’s finished.

What you also want to do is to add all the new sites to your Site Directory and use your custom Site Template that you have created.

So how do we do this? The answer is spelled PowerShell! But before we hand over to Niklas and look at the code we will take a look at the prerequisites. 

Site Directory
First of all we need to make sure that we have a Site Directory. The Site directory is a separate site that ships with MOSS and helps you sort and categorize your sites within a Site Collection. If you have created your Site Collection based on one of the publishing site templates you will already have the Site Directory. If not, you can create the Site Directory from the Create Site and you find the Site Template under the Enterprise section on the create new site page. The sites created in the Site Directory is actually just a simple SharePoint List. So you can add your own columns with your own metadata values which makes it possible to sort the sites on your metadata. You can also, as in our case, add a Business Data Column pointing back to SAP so that you can present SAP information in a standardized way on each customer site.

Click to see a larger picture

Site Template
In our case we want to use our own Custom Site Template, this is of course not necessary from a technical point of view but when structuring this amount of data you need to put a lot of effort in making a good Site Template that includes everything you need. Make sure that the document library has the right content types, Versioning Settings etc. because that is not something you want to do afterwards.

 
Click to se a larger picture

List of sites
To be able to create the 700+ sites we of course need some kind of source data. In our case we were able to get this list from SAP. We got an Excel worksheet that we exported from Excel to a CSV file. What we also need to take care of is that not all of the customers have URL friendly names. This could cause problems in the batch script but instead of modifying the list we got, we decided to move this in to the script and let PowerShell take care of that.

So, let’s move over to www.powershell.nu, stage is yours Niklas.

This can be done in three different ways. The first way to do this is to use SharePoint Designer and make a custom form field, there are a couple of good articles about this (but you should be aware of that this could in some cases cause problems with e.g. attachments not working properly without extra coding). The second way, and the easiest way, is with content type as I will guide you through today. This might on the other hand be the least flexible. The last way is by using PowerShell which I will get back to later in the article.

Start by going to your list that you want to modifye the form fields on, this could be any kind of list or library. In the list go to List Settings and then click on the Advanced List settings.

What you first need to do is to allow management of Content Types. Click on Yes and then Ok.

You will then return back to the List Settings page which now looks a bit different. You will see a new section called Content Type. In my example I have used an Issue list so what I have is the Content Type Issue like shown in the picture below. 

What you see now is a list of all the Site Columns that is connected to the Content Type Issue. This could have been any kind of Content Type, default or custom made that has default or custom made Site Columns.

By clicking on any of the columns you are able to do some modifications to the column. In the Column Settings section you have three options. Required, Optional and Hidden. By Selecting Hidden the form field will not show up in forms. You should however note that this makes the form field hidden both in the NewForm.aspx and the EditForm.aspx forms.

As I mentioned earlier there is a way to do this with PowerShell. By doing it programmatically you can part from the Content Type way just described decide which fields that should be visible individually between the NewForm.aspx and the EditForm.aspx. Since this solution is made by our PowerShell Guru I will simply link to his article and hope that this post was useful for you.