February 2008 - Posts

• What is a Meeting Workspace and how do I use it?

  The workspace is probably one of these most powerful features Sharepoint has to offer as far as collaboration is concerned, but not many people are aware of it or even know how to use it. This is not a new feature as it came from the previous version of Sharepoint 2003, but a lot of instability issues have been resolved. Workspaces rely heavily on two main aspects of Sharepoint to function properly: Profiles and MySite - The workspaces get created under a users "My Site" site collection by default and therefore the profiles need to be configured before workspaces can be used. Office 2007 - Workspaces can be created on the fly from applications like "Word" , "Excel" , "PowerPoint" and "Outlook" assuming that you are using Office 2007. A workspace is a temporary or permanent area where people can meet and collaborate on documentation and discuss agenda's, objectives and many other things. Let's for a moment assume that a user is creating a document in "Word 2007" and then realises that they need input and assistance from other people to complete the document. The document is not finished, so therefore it becomes quite difficult to decide where to put it on Sharepoint. The solution is to publish the document directly from "Word 2007" into a temporary workspace limited only to those people invited. The document is then completed in the workspace through collaboration with other users and then the document is posted to a final location in the Sharepoint hierarchy. At this point the workspace can be deleted as it is not required anymore. A more practical example of how a workspace can improve our day to day lives is by looking at it from an "Outlook 2007" perspective in regards to how we schedule meetings. In the rest of this blog I will explain how to create a meeting workspace using "Outlook 2007". Before we start taking a look at how "Outlook" uses workspaces, let me start by explaining the business problem that it solves and most likely how we work every day. What do we do when we want to schedule a meeting with certain individuals to discuss a particular document? We open Outlook and then navigate to the calendar. We then highlight the date and time in the calendar, right click and select "New Appointment". We attach the document to the appointment We invite various people to the meeting by selecting them from the global address list We complete all the additional fields and then we click "Send" This particular way of working creates a number of problems that we have just come to accept as normal: Users invited to the meeting either receive the email or they do not. If they do receive it, there is no guarantee that it will actually update their calendar upon receiving the email. Many users use this as an excuse to not attend the meeting. Many users have a limit to the size of the email attachments that they can receive. There is no guarantee that the email will actually reach the intended recipients. Many different copy's of the attached document is sent to the invited recipients. If each person modifies the document and sends it back to the sender, how do you consolidate the changes. Assuming people even know about "Track Changes" in MS Word. Quite often many discussions take place via email concerning the document. How do you associate this information with the document on a permanent basis without having to alter the document to include these discussions. Let's take a look how Workspaces in Sharepoint can give us an alternative way of working and then I will list the advantages. The initial process of scheduling an meeting in Outlook stay's almost the same. We navigate to the calendar and select "New" meeting. The major difference comes in the fact the we will not attach the document to the email, but instead we will create a workspace in Sharepoint directly from outlook. This is done by selecting the button on the ribbon called "Meeting Workspace". This action will open up a tool pane on the right hand side of the calendar item that will allow us to configure the settings for the workspace. The settings include the following options: Location - the workspace gets created under the users "My Site" by default, but can also be created under any Sharepoint site that the user has access too. Template - the templates determine what web parts and features become available in the workspace once it is created. Once these options have been configured, select the "Create" button to create the workspace in Sharepoint. The rest of the configuration options on the calendar item stays the same as usual. These options would include inviting the attendees to the meeting. Once the calendar item and the workspace have been created the invite is sent via email by selecting the "Send" button. The major difference in this email is that the document is not attached to the email, but rather a hyperlink is inserted in the document that allows the recipient to navigate to the meeting workspace when the time of the meeting arrives. It is typically a good idea for the initiator of the meeting to navigates to the workspace and prepare it for the meeting. This would depend on the template chose during the creation of the workspace but typically would include the following items: Objectives - the objectives about meeting about the document Attendees - this is the list of people that have been invited to the meeting via Outlook. More users can be added on an ad-hoc basis. Agenda - the list of items that need to be discussed concerning the document. Document Library - this is where all the documentation needs to be uploaded for sharing and discussion. Now that we know how to create a Workspace using MS Office, lets take a look at the advantages. People can now have meetings on-line without having to travel to a fixed location to have a meeting. This would be more conducive if combined with other technology's like "Office Communication Server" for audio and video. A single copy of the document is edited by all people involved in the meeting avoiding the need for consolidation of multiple documents afterwards. All discussions concerning the document is stored as meta data in the workspace and therefore linked to the document without having to alter the document itself. The email send out via Outlook only contains a link to the workspace therefore bypassing any restrictions based on attachment size. The workspace is secure as only the people invited to the meeting can attend the workspace. I hope this blog has convinced you that their are alternative ways of working that are a lot more productive than the way we have been working up to now. Related Blogs: The importance of Outlook 2007 as a user interface into Sharepoint Office 2007 Service Pack 1 released Microsoft Outlook 2007: A Productivity Tool? The purpose behind "My Site" in Sharepoint Posted Feb 25 2008, 09:46 PM by Neil with no comments Filed under: Sharepoint, Office 2007

• Creating a new Sharepoint site using Sharepoint Designer

  It is possible to create an entirely new Sharepoint web site directly from Sharepoint Designer without having to create them from within the Sharepoint web interface. This is quite useful if you intend customizing or branding the web site before publishing it live. The first step is to install SPD (Sharepoint Designer) from the Office 2007 DVD using your Enterprise Office licence key or you can purchase SPD separately with it's own key. Once the product has been installed, launch the application and then select "New" from the file menu and then select "Web Site". It is possible to create stand alone web sites using SPD, but that is not why it was built. Therefore we will select the "Sharepoint Templates" option on the left hand side of the dialogue box. At the bottom of the dialogue box you will have to specify the URL to use when creating the web site. This is quite important as the list of templates will be extracted from the Sharepoint web site and then made available in the middle of the dialogue box. Choose the appropriate template and select "OK" to create the site. The above screen layout is created when you double-click the "default.aspx" page in the folder list. In the next part of this blog I will discuss the Sharepoint Designer IDE and what the various windows are used for. There are basically 6 main areas that we can work with: Design Pane - this area is used to visually update the web page Code Pane - this area displays the HTML that is generated by the design pane and gives you the flexibility to have more finer control. Folder List - this window show all the files and web parts that are being used in this site. Properties -  this window displays all the possible setting for an element selected in the design pane. Toolbox - this window allows you to add additional controls and web parts to the page. Styles - this window allows you to control the look and feel of the page using cascading style sheets. Lets take a closer look at the Folder list. The folder list is used to separate the content in the site using a logical structure. As more content is added, more folders are created. Here is a summary of the standard folders that get created: Catalogs - this provides access to the Master Page Gallery for the site. All aspx pages inherit from a master page. Private - used internally by IIS Images -  used to store any images used on the site. Lists - used to refer to list like contacts, calendar, announcements, tasks and many more. m - m stands for mobile. As various pages are created on the site, Sharepoint automatically renders them for mobile devices. Document Library's - used to refer to all the document, picture and forms library's used in the site. Surveys - multiple survey's can be created per site and this folder is used to refer to them. Publishing - only valid if you used the publishing template when creating the site as this allows you to create new page layouts. Workflow -SPD allows you to build custom workflow rules to automate you business processes. Default.aspx - all web sites have a default page that is rendered first, that inherits from the default master page. Lets take a closer look at the properties window. The properties window consists of two tabs that are directly linked with the elements on the design pane: Tag Properties - various items can be selected in the design pane and then their properties are listed on this tab. The items are effectively HTML tags as we are building a web page. Most tags have sub elements that can contain various values. These are listed on this tab as individual properties. CSS Properties - the formatting of various items in a web page is controlled through cascading style sheets. This tab highlights only those elements of the style sheets that apply to the currently selected item in the design page. These can then be changed. Lets take a closer look at the toolbox. There are a number of tabs on the toolbox that allow us to do various things: Toolbox - this tab displays all the default controls that are available with the .NET Framework 3.0. These are the same controls that are used in Visual Studio and are now available in SPD for use on web pages. Web Parts - all the standard web parts that form part of a WSS or MOSS deployment was well as any custom web parts that are installed on Sharepoint are available here. These can be placed in web part zones on the page. New zone's can also be created using this tab. Data Sources - this tab allows you to create connection to external database like SQL Server , Oracle, DB2 and many more. The data from these databases can then be displayed inside a web page using data views. Lets take a closer look at the Style Sheets window. There are two tabs on this screen called: Apply Styles - these are a number of default cascading style sheets that come with the default.master page. These have already been applied to the default.aspx page, but the can be modified. Manage Styles - new style sheets can be created and then applied to any component within a web page. Using all these tools to our disposal, we can create exception Sharepoint web sites that do not look anything like the standard look and feel that we are used too. Go and look at a live web site at http://www.glu.com for a very good example of what can be done. Related Blogs: SharePoint Designer - Overview Minimal Master page in Sharepoint Designer Sharepoint Designer Service Pack 1 released Posted Feb 24 2008, 02:53 PM by Neil with no comments Filed under: Sharepoint, SharePoint Designer

• The purpose behind "My Site" in Sharepoint

  The concept of social networking has become very popular in the last two years with sites like "Face Book", "My Space" and "Linked In", but company's are afraid of it's impact on performance of their employees. The general trend therefore is to block these sites on the firewall, but the business benefit of these tools are lost to many. In this blog I will attempt to illustrate the concept and benefits of social networking and offer an alternative internal option in the form of "My Site" that forms part of MOSS. Before I do that, lets take a look at some common business and IT problems that we face every day: Most users store their documents on their local machine and not on the file server. The documentation therefore does not get backed up on a regular basis and the company faces the risk of losing vital information. The information stored on file servers is normally very unstructured as the users are allowed to create any directory structure that they please and therefore it becomes increasingly difficult to find what we need. Security is quite often non existent as the users do not have control over the NTFS file system and have no idea how it works. Our security is therefore based more on ignorance than any real attempt to protect the information. Contact information like telephone numbers, email and IM is normally maintained in Excel spreadsheets and corporate Intranet web sites that get outdated very quickly and are not dynamically updated. Email gets abused on a daily basis as users use it to share files among each other. This puts huge amounts of strain on our email servers and quite often creates huge delays and blockages. Most company's have no idea what ECM (Enterprise Contact Management) is and therefore we keep on buying bigger and bigger file servers and backup devices in an attempt to manage content that nobody needs anymore. Sharepoint site hierarchy's can be become very complex and therefore daunting to the average user. Where do they put their documents? Which site collection? Which site? Which document library? What folder? What content type? The HR databases are normally fairly inaccurate once an employee joins a company as any changes in the employees life and education are not reflected back into these systems due to a lack of communication. Many of the problems that I mentioned in the bullet points above can be solved by using Sharepoint, but each users "My Site" is the entry point into this solution. If you get the users to buy into the concept of "My Site", then it becomes easier to get them to use the rest of the solution. Lets take a look at some the the advantages that "My Site" has to offer: The users "My Site" is a site collection, therefore many sites can be built below the top level site making it easier to structure the information and getting the user to understand the concept of a web based hierarchy. Document library's exist to store the users information so that there is no more need to leave it on the local machine in "My documents". The first time a user attempts to access their "My Site" they are prompted to make this the default save location for MS Office 2007. From this point onwards, all Office 2007 applications will default their save location too "My Site. The site has a public and private view off all the content, allowing the user to determine what content is private to them and what content they would like to share. The public content can also be more finely controlled by adding other users on Sharepoint into security groups and then limiting them to what they can see. Sharepoint allows a user to create temporary workspaces from within the Office 2007 applications so that they can share live data with other users in on-line meetings. These workspaces are created below a users "My Site". Outlook web parts are available allowing the user to access their inbox, calendar, contacts and tasks on Exchange directly from here without the need to log onto "Outlook Web Access". Profile information about the various users can be imported from AD or an HR database via the BDC. This profile information can then be updated and maintained by the users themselves. Another big advantage is created by certain web parts that allow content roll up from all other sites in Sharepoint. Users are continuously placing documents , alerts, records and many other content all over Sharepoint. These web parts allow them to access all that information from "My Site" without having to navigate to the specific location. The snapshot picture above gives a breakdown on some of these web parts and their purpose. Their is also a tab at the top of the "My Site" called "My Profile" that allows users to modify their personal information. The profile information can include a number of very useful bits of information: Personal picture of yourself (Be Honest, this is not a dating service) Responsibility's (Normally left blank) Skills Past Projects Schools Interests All of this information gets indexed and therefore becomes available for searching. Now it becomes possible to find skills within your own organization before looking externally. I hope that I have convinced you of the importance of using "My Site" in an successful Sharepoint implementation. Related Blogs: The importance of Outlook 2007 as a user interface into Sharepoint Overview of Shared Service Providers in Sharepoint Overview of User Profiles in Sharepoint Posted Feb 17 2008, 04:37 PM by Neil with no comments Filed under: Sharepoint, Office 2007

• ASP.NET error registering with IIS

  This is a very common error that people experience when attempting to host an ASP.NET application on a new server. I will be explaining the solution to this problem from a Sharepoint perspective, but the information is relevant to many other scenarios. The problem normally occurs on new servers that are being configured to host .NET application for the first time and can be avoided entirely by changing the installation sequence. Many applications required both the .NET framework and IIS to be installed on the server and depending on which one you install first, this problem does not occur. If you install .NET framework before installing IIS then you will not have this problem. Change the sequence around, then you need to read this blog. A lot of people experience this problem when attempting to install either WSS or MOSS on a Windows 2003 server. They start by installing the pre-requisites for Sharepoint: Service pack 1 for Windows Server 2003 Install IIS 6.0 on the Server Install the .NET Framework 3.0 Install SQL 2000 with sp4 or SQL 2005 with SP2 or SQL 2008 The next step would be to run the setup.exe from the Sharepoint CD and then they get the following error. This problem was caused by the installation sequence I mentioned earlier and if you re-install the .NET framework as the dialogue box suggests, the problem will be resolved, but there is a faster way. There is a command line utility available in the directory where the .NET framework is installed that will fix the problem. Open windows explorer and navigate to the following directory: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727". In this folder you will find an executable called: "aspnet_regiis.exe" that you need to execute from the command line with a particular switch to re-register the ASP.NET component with IIS 6.0. Open the command line console by selecting start, run and typing cmd and then pressing enter. Navigate to the directory mentioned above and type the following command. The command syntax is: "aspnet_regiis -i". Once the registration process has been completed. Close the command line and open the IIS management console. Navigate to the folder called "Web Service Extensions" and confirm that the ASP.NET component has been successfully registered with IIS. At this point you can attempt to install Sharepoint again and there should be no problems. Related Blogs: Overview of the .NET Platform Installation Procedure for MOSS .NET 2.0 Framework Posted Feb 07 2008, 09:28 AM by Neil with no comments Filed under: Sharepoint, .NET, IIS

• Joining a WFE server to a Sharepoint Farm

  When installing Sharepoint for the first time a very important decision needs to be made. Are you installing as a "Stand Alone Server" or are you installing into a "Farm" configuration. In a "Stand Alone" configuration all the elements that define Sharepoint are installed on the same server (Web, SSP, SQL) and it is very difficult to split them at a later stage. Therefore it is better practice to install into a farm configuration even though you might only start with a single server. I have already written a blog about how to install the SQL server component remotely. In this blog I will explain how to add another web front end server (WFE) to a Sharepoint farm configuration. The configuration that I have in mind will include the following servers: Web front end server 1 - Web, Admin Console, SSP Web front end server 2 - Web , SSP SQL Server - all the Sharepoint databases Assuming the Web front end server 1 and the SQL server have already been deployed, lets take a look the the steps involved to add web front end server 2 to the farm: Install the binaries onto the server from the Sharepoint DVD. Run the Configuration wizard on WFE 2 Confirm in the admin console that the server has joined the farm. The steps to install the binaries onto the server I have already explained in a blog titled "Installation procedure for MOSS", therefore I will start with the configuration wizard. The first dialogue box in any wizard is the welcome screen explaining the purpose behind the wizard. Once you have confirmed that you know all the information required for the wizard, select next. A dialogue box will warn you that the Sharepoint services will be stopped while the wizard configures the new server into the farm. Select "Yes" to stop the services and make sure that you are doing this after hours. The next screen on the wizard asks a very important question. Are you joining an existing farm or are you creating a new one. In our case we will be joining the farm. Click next. If you are joining an existing farm then the configuration database must already exist as the installation of the first WFE would have created it. The questions posed on this particular screen therefore pertain around the location of the configuration database: Name of the SQL Server Name of the Configuration Database User account with right on the SQL server Password for the user account selected Once all these settings have been confirmed the next button will be enabled. The next screen is used for confirmation that all the settings supplied are correct before the configuration will commence. There is an advanced button available that gives us some more options. The advanced settings allow you to decide whether this server will be used as a web front end server with all the services or if you just want to use it to host an SSP configuration with services. In our case it will host the the web sites as we are creating an WFE. Select "OK" and then select "Next". The wizard will not proceed and add this server into the farm configuration. This can take a while so go and make some coffee. Once the wizard has completed the process it will end with a "Success" or "Failure" confirmation screen. Select "Finish" and navigate to the Sharepoint Admin Console. On the "Home" tab in the Sharepoint Admin Console a summary will be displayed called "Farm Topology" If everything was successful then the new WFE should appear in the list. You can now use the "Services on Server" option on the "Operations" tab to start as stop services on the different servers. Related Blogs: A developer's 101 to installing Windows SharePoint Services 3.0 Installation Procedure for MOSS Installing MOSS with a remote SQL Server Overview of Shared Service Providers in Sharepoint Posted Feb 06 2008, 11:40 AM by Neil with 3 comment(s) Filed under: Sharepoint

• Using Sharepoint without the Web Interface

  Many people are not aware of this, but all the sites in Sharepoint and their content can be accessed from your desktop PC without using a web interface. This is not some add-on or miracle solution create by a .NET developer but an automatic process built into Windows XP and Windows Vista. When opening "Windows Explorer" on you machine and collapsing out the the tree structure, you will find and area called "My Network Places". This node is automatically populated with shortcuts to network locations that the user visits on a regular basis. The idea behind this is so that network administrations do not need to map network drives for the user as the OS will do this automatically. It is also possible to add you own shortcuts manually. All the sites in Sharepoint that a user navigates to are also mapped to "My Network Places" over time. This normally occurs when a resource such as a document or list is accessed for the first time and content is either submitted or extracted. The link can then be expanded using windows explorer as Sharepoint also uses an Hierarchical structure to organize the data. As you can see from the screen shot above, all the content in a Sharepoint site is represented as different folders with different icons. The folders are divided into three types: Sub Sites - other Sharepoint sites that form part of the same site collection. Document Library's - this is where all the documents are stored in Sharepoint Lists - this represents structured information like calendars, contacts, announcements or even custom lists. By selecting a sub-site you will drill down further in the hierarchy and be represented with a similar view than the one we are currently reviewing. Unfortunately all the lists that have been created in the site required a web interface to capture the data. Therefore the only thing you will see when selecting them is the "aspx" pages used in Sharepoint. By double clicking on a selected web page, Internet explorer will be launched and the user will be taken into a web interface representing the list in Sharepoint. Developers can potentially created alternative solutions for this by connecting to the XML web services running on the Sharepoint server, but there is no quick fix out of the box. The big advantage that this particular view of Sharepoint offers us is based around the document library's. If you select a folder representing a document library, then all the documents stored there in will be displayed in windows explorer and can be manipulated. An document type can be added, edited or deleted from this location without the need of a web interface. This solves a problem that a lot of people face when initially deploying Sharepoint. How do I move all the documentation including the current directory structure from "My Documents" into Sharepoint without having to do it one by one through a web interface? It is a simple matter of "Dragging and Dropping" or "Cutting and Pasting" files or folders from any location that the user has access too and then placing it into the document library. The communication process between Windows Explorer and Sharepoint is done via and application level protocol called "WebDav" and uses "HTTP" as the transport layer. In another Blog I might elaborate on this. Last thought before I conclude: Is this the best way of getting information into Sharepoint? The argument could be raised that most users have complete garbage in "My Documents" and our file servers are storing terabytes of information that nobody will ever use. If you just allow users to randomly upload huge quantity's of information in Sharepoint then all we are doing is converting our file servers to a web interface. Maybe we should use the Sharepoint implementation as an opportunity to do "House Cleaning" and become fairly selective about what we store? I leave the thought with you. Related Blogs: The importance of Outlook 2007 as a user interface into Sharepoint Offline Sharepoint documents in Groove Rendering Sharepoint sites to Mobile Devices Posted Feb 02 2008, 10:04 PM by Neil with no comments Filed under: Sharepoint