7/3/2008In my previous blog I wrote on how to use PowerShell to do various things in SharePoint. Well today I had to a lot of information on site collections in a farm. Things like list all the site collections in all web applications and show the owner, owner email, URL, name, quota, actual size etc. Just a lot of useful information about the site collections in the farm. I can get most of the information from the central admin, but I would need to copy and paste in a lot of different places and it would take a looooong time if there is a lot of web applications and site collections. I could also use stsadm with operations like enumzoneurls and enumsites. That would simplify the task, but it would still require manual effort and it would not be very repeatable if I had to do it on regular intervals. I thought about PowerShell as well, but PowerShell was not installed in the environment and I could not install it due to various operational reasons. Then I thought about .Net Framework. It was installed on the server (requirement for SharePoint), and it comes with a C# compiler. I could use my trusty old Visual N++ development environment that comes with every install of windows. (That is Notepad for those who don't know) And then compile it with csc and pull the reports that I want to. I am not a real developer, so I struggled a bit to write the script and to compile it. Here is my effort for the script and how to compile it if you need to do something like this quickly and don't have time to play around. C# Script: | using System;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration; class MainApp {
public static void Main() {
Console.WriteLine("{0}\t{1}\t{2}\t{3}\t{4}\t{5}\t{6}\t{7}\t{8}\t{9}","AppName","AppUrl","HostName","SiteTitle","SitUrl","Size","Quota","Owner","EMail","Template");
SPFarm farm = SPFarm.Local;
SPWebService service = farm.Services.GetValue<SPWebService>("");
foreach (SPWebApplication webApp in service.WebApplications)
{
foreach (SPSite site in webApp.Sites )
{
Console.Write("{0}\t", webApp.DisplayName);
Console.Write("{0}\t", webApp.AlternateUrls[0].Uri);
Console.Write("{0}\t", site.HostName);
Console.Write("{0}\t", site.RootWeb.Title);
Console.Write("{0}\t", site.Url);
Console.Write("{0}\t", site.Usage.Storage);
Console.Write("{0}\t", site.Quota.StorageMaximumLevel);
Console.Write("{0}\t", site.Owner.LoginName);
Console.Write("{0}\t", site.Owner.Email);
Console.WriteLine("{0}#{1}", site.RootWeb.WebTemplate,site.RootWeb.WebTemplateId);
}
} }
} | And then more important the command line to compile: | csc.exe /debug+ /out:.\get-hmc-wss-info.exe get-hmc-wss-info.cs /reference:"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI\Microsoft.SharePoint.dll" | The part I struggled with was setting the reference to the SharePoint assembly. The command line above shows how to add the reference for the using clause in the code to work. Lekker Scripting 7/2/2008 In the first of this series of articles discussing Microsoft Enterprise Search we covered some of the common and most important challenges associated with enterprise search and why it's so different to Internet search. In this second article we will explore Microsoft's vision and strategy including the recent FAST acquisition.
Microsoft's vision for enterprise search is pretty straight forward and on the face of it very simple: enterprise search will change the way people interact with information. Think about this statement for a minute and you will begin to realise just how strategic search can and should be for your business because of the value it can deliver to the organisation in the form of driving up productivity and delivering new business models or revenue streams through new and unique user experiences. We believe that search will be everywhere and you can already see this starting to manifest itself in nearly all of the user interfaces that Microsoft is delivering these days, as well as other non-Microsoft products. Case in point: I recently had the software for my in-car communication and entertainment centre upgraded and quickly discovered that searching using free text for Thai takeaways near me is now possible. For me this was when the penny really dropped - that search is already "getting everywhere" and we're only at the beginning! Wait until you see what solutions have been built using the FAST platform that really don't even look like the traditional search we're used to - yet the experience is all driven by search under the covers. More on this later in the series. This brings us neatly onto the FAST acquisition and how the technology complements the rest of the Microsoft offerings around enterprise search. Microsoft bought FAST for three reasons: the bright and very experienced people, their vision and thought leadership in the industry - around enterprise search and of course, their technologies such as FAST ESP. It's important to point out that the FAST platform complements the rest of the search solutions we have in the market already. Where Search Server and SharePoint Server stops in terms of capabilities is pretty much where FAST ESP starts. Make no mistake here, Search Server and SharePoint Server are still very good solutions that compete extremely well and normally beat the most obvious products from other vendors. Not every business that is starting out with search or looking for traditional search capabilities will need FAST ESP - but we definitely believe every business should have search in some form because of the value it has to offer the business as already discussed. The key message here is that we see three market segments: entry level, infrastructure and high end. Before the $1.2bn acquisition Microsoft was well positioned to offer customers great choice in technologies to cater for entry level search requirements (Microsoft Search Server Express or Microsoft Search Server 2008) and an infrastructure search solution (Office SharePoint Server 2007) which delivers a rich set of capabilities that forms part of what we call the Business Productivity Infrastructure - I dare say that search is one of the capabilities that should exist in any real business productivity infrastructure. However these solutions did not and do not address all of the requirements (especially the really sophisticated and complex requirements) our customers were discussing with us and so the FAST platform now rounds out the Microsoft search offerings so that our customers have a complete and rich set of options to choose from when trying to decide on how to deliver search for their businesses. 
This puts our customers in a very strong position because there is no longer the need for compromise when looking at the Microsoft set of offerings. We're confident that there is a right solution to fit the requirements of any customer! In the next and last in this series of articles we will explore the road ahead for Microsoft Enterprise Search and how we plan to integrate FAST. I will also share some very good reference sites for your exploration on Microsoft Enterprise Search solutions. In the mean time, please don't hesitate to contact me if you would like to discuss enterprise search in more detail and see some demonstrations on how search and drive up productivity or bring new business models. Please contact me at roryhw at microsoft dot com 6/23/2008 Welcome to the first of a series of 3 blog articles covering what is arguably one of the most exciting areas of Microsoft to be a part of these days - helping people navigate, find, use and share information using enterprise search solutions. In this series I would like to share with you my view on what enterprise search is all about, why it's important and how to get going with enterprise search in your organisation.
This enterprise search series will cover 3 topics which I hope will give you more food for thought and get you thinking a little bit differently about what search in the enterprise really means. I have been in many customer and partner discussions about enterprise search and have found that there are many variations in opinions about how they can deliver what is needed to help business and IT people easily find information in the enterprise. The 3 articles will cover these topics: - Internet Search != Enterprise Search - The Enterprise Search Challenges
- The Microsoft Approach to Enterprise Search - Microsoft's Enterprise Search Strategy
- The Road Ahead - Microsoft's Enterprise Search Roadmap and Vision for the Future
So lets get going with the first in the enterprise search series: Internet Search != Enterprise Search Have a question for you: when you're on the internet and you need to find information, where do you go to search for it? Yup..... Live Search..... right? :) Ok but seriously, you definitely know where to go to find information on the web. Now let's ask this question: when you're at work and you're looking for some information about "that project you've just started working on" or "the new product your company is about to launch" - where do you start looking for it? You're probably not sure where to start looking right now or you're about to ask someone near you who you think might know where to start looking. Or you just don't know..... Right? This is exactly the problem in the enterprise, there is no clarity on where to look for stuff and there is no proven and repeatable way for people to find information inside the firewall. This is because information is scattered all over the place in many different information silos. Indeed, this is the reason why many leading organisations are spending so much time thinking about how to solve the problem of finding information. Before we get into how Microsoft can help to solve this problem (later in this series,) lets take a look at what the challenges really are. We'll look at the challenges in 3 logical areas: IT challenges, data challenges and user challenges. IT challenges Ranking and relevance - first up and definitely most important aspect about search from a user perspective is relevance and ranking but this challenge fits squarely in the IT space and how IT addresses this challenge... Internet search engines all use a similar algorithms for ranking the relevance of the results they give back to you when you run a search and this is the most common misunderstanding about the difference between internet search and enterprise search. When people are creating content for the web they are usually thinking about how people are going to find the information through a search engine and typically put a fair effort into the meta tags that go into the HTML header or metadata fields of a page or document. Another important aspect of web content is linking - the more your page is linked to from another page or the more your page links to other pages has a direct impact on the ranking your page will achieve from the internet search engine's ranking algorithm. This is very suitable and works extremely well for internet search. However, for the enterprise this does not work because people at work don't create that intranet pages, documents or presentations with the intention of their content being found by the internet search engine and they certainly don't link to other documents or vice versa. This fundamental difference in the way people create and share content at work renders the traditional internet search engine's algorithm irrelevant. Security - this is another fundamental difference between internet and enterprise search. Think about this: nearly all information on the web is accessible anonymously. Contrast this with information in the enterprise which is by definition all secure. This presents new challenges in ensuring that the search solution you choose is able to respect the security model of data in all your information silos and not just the common ones like file shares and content management systems. Scalability and management - so granted the end users don't care about this stuff but IT really do because they have to run and manage the solution. The notion of one size fits all doesn't suit enterprises who seek flexibility in how they architect and grow their systems. Likewise, having multiple management interfaces and skill sets for managing solutions drives up cost of ownership. Data challenges Structured and unstructured data - searching content on the web is pretty straight forward when you start comparing this to how many information silos exist within just one typical company. On the web everything is accessible over HTTP and the content is usually HTML, PDF, Word, Excel or some other very common file format. In the enterprise there is usually a need to search the document libraries like File Shares, SharePoint or FileNet, the CRM data, the ERP system, a couple of bespoke written applications on Oracle or something else and maybe another type of solution like a 3rd party library. This presents significant challenges for IT because connecting to all of these data silos and respecting their data and security models without an extensible platform makes it very difficult if not impossible to achieve and if the search solution can't do this, it usually offers less value to the business than if it could connect to all the silos and make information across the enterprise truly searchable. Expertise location - analysts say that around 80% of a corporate's knowledge is tacit which means it's inside people's heads. This is one of the key drivers for a knowledge management system and culture in the enterprise. It's about getting stuff out of people's heads and into the more permanent corporate memory. Generally KM tends to do well when it's planned and implemented properly but the challenge of finding information still exists and so expertise location is equally, if not more important that searching data already in the enterprise. In my view there are two ways of achieving expertise location. The one is through asking people to manage their own profiles manually - such as their MySite on SharePoint - the enterprise equivalent of the well known (unless you've been under a rock lately) :) Facebook profile. The smarter and more sustainable way is by using technology to build profiles for people automatically and of course Microsoft is working hard at this right now and you will see some exciting stuff coming in the Office System 14 release next year! User challenges Single UI and login and unified results - this is one of the areas that can really make a difference for the users and adoption of search. When we talk about search at Microsoft the aim is to either improve productivity or enable new business models and in the former, how can users be more productive in finding information when they have to use multiple applications to find what they're looking for. Imagine trying to find information about a customer using CRM, ERP, your desktop and the intranet web content as your sources but running individual searches across these repositories. Contrast this with visiting "the intranet" and running one search - or running one search from your desktop and getting all the results back. The same is true for login to systems. The user is already logged in. Why not just access to the items in the results without being challenged to log in. This is an area that will always need more work as it's not just a search problem. In IT we've been talking about single sign-on for many years now and it's gotten a lot better but not yet perfect... So these are some of the most common challenges around enterprise search and I hope you're starting to see that searching the enterprise is a different ball game when you compare it to good old internet search where the content is uniform and security is not such a challenge. Look out for my next article in this series: The Microsoft Approach to Enterprise Search - Microsoft's Enterprise Search Strategy coming to an RSS reader near you soon... 6/19/2008We had a community meeting on the 19th of June 2008 and I did a presentation to give an overview on why and how to use PowerShell in a SharePoint environment. This blog is partly to post the commands that I used in the presentation and partly to explain how to other stuff with PowerShell that I was asked about in and after the Presentation. The demo was about provisioning different lists in a site in SharePoint. The first step in connecting to SharePoint is to load the necessary .Net library. This can be done with the following command: | [system.reflection.assembly]::LoadWithPartialName("Microsoft.Sharepoint") | I went through the following commands in the demo. I added comments in to explain what is happening. | $site = New-Object Microsoft.SharePoint.SPSite("http://adbmoss") # Connect to the site collection http://adbmoss and store the object in the $site variable $site | get-member # Display all the properties and methods for the object in $site $site.set_readonly($True) # Set the site collection to read only. No updates are allowed $site.set_readonly($False) # Set the site collection back to read-write $root = $site.rootweb # Connect to the root site in the site collection and store the object in $root $root | get-member # Display all the properties and methods for the object in $root $root.lists | format-table -property title, author # Display title and authors for all the lists in the root site $root.lists | ?{$_.iscatalog -eq $null} | format-table -property title, author # Filter the lists to show only the user lists. The $_ symbol refers to the object in the piple line. The ? symbol is an alias for the where-object commandlet. $root.listtemplates | format-table -property name # Show all the available list templates for the root web $TempCal=$root.listtemplates["Calendar"] # Store the Calendar template in a variable $TempCal $root.lists.add("Events","Company Events", $tempCal) # Create a list called “Events” with Description “Company Events” on the calendar template import-csv dept.csv | %{$root.lists.add($_.Dept, $_.Descr,$root.listtemplates[$_.Temp])} # Create a new list for ever line in a CSV file where the name for the list is saved in the Dept column of the file, the description is in the Descr column, and the type of list to create is in the Temp column. First check that the lists are correctly created before you continue. The % symbol is an alias for the foreach-object commandlet and places each instance of the collection in the pipeline one after the other. import-csv dept.csv | %{$root.lists[$_.Dept].delete()} # Use the CSV file again to delete all the create lists again. | You can get the sample CSV file here. In the presentation one of the delegates asked if PowerShell can be used to provision additional columns in a custom list as well. The answer is yes, and the following commands show how to accomplish that. | [system.reflection.assembly]::LoadWithPartialName("Microsoft.Sharepoint") # Load SharePoint library $site = New-Object Microsoft.SharePoint.SPSite("http://adbmoss") # Connect to the site collection http://adbmoss and store the object in the $site variable $root = $site.rootweb # Connect to the root site in the site collection and store the object in $root $root.lists.add("CTest","Custom Test",$root.listtemplates["Custom List"]) # Create a new list called “CTest” from the template “Custom List” $list = $root.lists["CTest"] # Set a variable $list to the custom list that was just created. $list.fields.add("T1","Text",0) # Create a new field of type Single Line Text with the name of “T1”. The field is not required (last parameter) | After the presentation I had a question if PowerShell can be used to update metadata in a document library. The scenario was that the documents were already in the library and they had a spreadsheet with the id number of the document and some additional meta-information. This can also be done in PowerShell. The first step is to save the spreadsheet in CSV format or any other format that PowerShell can easily import. The following code shows how to go about importing the metadata. | [system.reflection.assembly]::LoadWithPartialName("Microsoft.Sharepoint") # Load SharePoint library $site = New-Object Microsoft.SharePoint.SPSite("http://adbmoss") # Connect to the site collection http://adbmoss and store the object in the $site variable $root = $site.rootweb # Connect to the root site in the site collection and store the object in $root $docs = $root.lists["Shared Documents"] # Store the Shared Documents document library in a variable $Docs import-csv DocProps.CSV | %{$item = $Docs.items[$_.id]; $item["Title"] = $_.Title; $Item["Group"] = $_.group; $Item.Update()} # Loop through the csv file and update the properties | The last line of this script is a bit cryptic. I will break it out in the next few lines to explain the detail of how it works. The following lines might not work if you copy and paste it. | import-csv DocProps.CSV # Import the data from the DocProps CSV file | # Pipe the results to the group %{ # For each (%) line in the csv file do begin ({) $item = $Docs.items[$_.id]; # set the variable $item to the entry in the list where the id corresponds to the id column in the file. The semicolon (;) indicates the separate command is to follow $item["Title"] = $_.Title; # set the title of $item to Title in the file $Item["Group"] = $_.group; # set the Group metadata property to the group Column in the file $Item.Update() # update the entry $item in the list } # End (}) the loop | You can get the sample CSV file here. As you can see the one liner in PowerShell can be very complex and powerful. Just keep your head. You can download PowerShell from the Microsoft download site. There is a few download links: PowerShell 1.0 English for Windows 2003 PowerShell 1.0 English for Windows 2003 x64 PowerShell 1.0 Graphical Help File Happy Scripting 5/28/2008Microsoft has recently release search connectors to IBM FileNet and EMC Documentum for MOSS 2007 and MMS 2008. The links to download the connectors are: Enterprise Search Indexing Connector 2008 for IBM FileNet and Enterprise Search Indexing Connector 2008 for EMC Documentum. In addition to this Microsoft also release tutorials on how to install the connectors. The tutorials shows the install for small server environments. The tutorials can be viewed at: ESIC2008 for FileNet tutorial and ESIC2008 for FileNet tutorial. The reason why I limited the title for this blog to the FileNet connector is because I have had some experience in the last few weeks in installing and using the connector in an large corporate in South Africa. I want to share some of the experiences I had with installing and configuring the connector. The connector uses the FileNet Content Engine Client to connect to FileNet. We could install the client on the indexing server with the SharePoint administrator, but we could not configure it to connect to FileNet. We eventually used the FileNet administrator account to install and configure the FileNet Content Engine Client on the SharePoint Servers. Our original environment consisted out of a 32 bit indexer and 64 bit web front ends. We could install the the connector on the indexer, but not the WFE's. The error on the WFE was "This product requires Windows SharePoint Services 3.0". The actual error is that the connector is not supported on 64 bit servers. You need to have the indexer and the WFE servers in 32 bit node. The reason for this limitation is that the FileNet client is only available in 32bit and you need 32bit SharePoint to use the 32bit FileNet client. The indexer uses the client to index the documents and the WFE servers uses the client to open and view the document in FileNet. Once we managed to install the connector we had problems configuring it. We got access denied errors. Eventually after a lot of trail and error we managed to configure the connector by using an account that is both a FileNet administrator and and a SharePoint farm administrator. We hoped that that was the end of the problems, but when we tried to crawl the FileNet object stores we got access denied again. We eventually traced all these access denied error back to the fact that the search and crawl user accounts tried to open DCOM connections from the SharePoint server to the FileNet server. We bypassed this by making the search and the crawl accounts local administrators on the FileNet server. This did the trick and we are indexing FileNet now. You also need to make sure that Network DCom is enabled on both the FileNet and SharePoint servers. Making these accounts administrators in FileNet is far from ideal. I have theory on how to reduce the necessary permissions to do the crawls. This involves giving the crawl and search accounts launch and activation permission on the CE DCom object on the FileNet server. We are currently in a testing freeze and I will update the blog if I have proof that this works. Happy Searching 4/22/2008Microsoft provides a bunch of templates for Windows SharePoint Services 3.0. These templates make it easy to start new SharePoint sites for common functions like Help Desks, Lending Libraries, Call Centres etc. The sites from these templates can be modified to meet the users' specific needs. The templates can be downloaded from the Microsoft download site at http://www.microsoft.com/downloads/details.aspx?FamilyID=5807b5ef-57a1-47cb-8666-78c1363f127d&DisplayLang=en. A number of newcomers to SharePoint have tried to install this from the readme file that comes with the templates and have failed. Or if they succeeded was frustrated with the long process involved in deploying the templates. I decided to share my experience here in simplifying the SharePoint templates. Copy and Paste does not work. The first thing people get stuck at is that they try to copy and paste the commands from the readme file into the command line and SharePoint responds with a command line error message. The first reason for this is that the stsadm utility is not in the path and you did not specify the full path to in in the command. Either add the full path to the utility when executing or add the SharePoint BIN folder to your path environment variable (I recommend changing the path because it will save you a lot of frustration later on). The default location for the BIN folder is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN The second reason for this is that there is a line break in the middle of most of the command samples in the readme file. This is done for readability of the instructions. You need to delete the line breaks in the file and make sure you have the entire command on a single line before you copy. The third thing that goes wrong with the copy and paste is that the "-" in the command line is actually a "–". It looks almost the same but it is not. After you pasted the delete the "–" from the command line and replace it with the "-" character. You can get it by pressing the <minus> key on your keyboard (Above the + on the numeric side or to the left of the + on the top row). The right one is usually slightly shorter and thicker than the one you pasted from the readme file. The forth thing that goes wrong the "-o deploysolution" needs "additional attributes depending on your configuration" but it does not say what. Here are the three options you have: - -local Add -local after the command line if you have a standalone server for SharePoint. That is the basic install with everything installed on the same server.
- -immediate Add -immediate after the command line for all other install types. This will deploy the template to all front end servers in the farm. Even if there is only one.
- -time <time to deploy> Add -time after the command line instead of the -immediate if you want to schedule the deployment to happen at a different time (e.g. after hours)
It is a long process to deploy all the templates After you sorted out all of the previous issue and deploy the templates you soon realize that it is a long and boring process to install all the templates. And people usually make mistakes when stuff gets boring. I wrote two batch commands for the command prompt to help with the deployment. The first, called DeployA.bat, will install all the templates in the current folder. First it installs the ApplicationCore template. This template has to be installed before any of the others and have slightly different install steps. It then renames the ApplicationCore template to *.old, this is to ensure the next stop does not install it again. The next step then loops through the remaining .WSP and deploys the templates. The second, called DeployT.bat, deploys a single template. It takes one parameter and that is the name of the template that has to be deployed (e.g. Template.WSP). This will deploy the template immediately. You can change the file for local installs or if you want to make a timed deployment. You can just add the two batch files into the same folder as the other templates and run DeployA to install all the templates. You have to make sure that the SharePoint BIN folder is in the path environment variable. Check for any error messages while the batch jobs are running. I have not build in any error control into the batch files yet. The batch files looks like follows: DeployA.bat | @Echo off
Call DeployT ApplicationTemplateCore.wsp
stsadm -o copyappbincontent
ren ApplicationTemplateCore.wsp ApplicationTemplateCore.wsp.old
for %%f in (*.wsp) do call DeployT %%f | DeployT.bat @echo off
echo Deploying %1 ...
stsadm -o addsolution -filename %1
stsadm -o deploysolution -name %1 -allowgacdeployment -immediate | You can download the scripts here. I hope you have hassle free deployments Andre | Edit in Browser | /_layouts/images/icxddoc.gif | /blogs/ZA SharePointers/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /blogs/ZA SharePointers/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /blogs/ZA SharePointers/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /blogs/ZA SharePointers/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /blogs/ZA SharePointers/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /blogs/ZA SharePointers/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /blogs/ZA SharePointers/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /blogs/ZA SharePointers/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /blogs/ZA SharePointers/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
|
|