• Category Archives WSS 3.0
  • SharePoint – Custom Master Page Seen as V4 When Built for V3

    Just so it is clearly understood, SharePoint 2010 came with the capability to display the master pages of migrated 2007 sites. This capability therefore differentiates the master pages of the two environments into two categories: V3 (SharePoint 2007/WSS 3.0) and V4 (SharePoint 2010/Foundations).

    So I came across an issue where we began migrating our existing 2007 environment to SharePoint 2010. We had a custom master page and theme feature rolled out on the 2007 environment. We needed to maintain this master page post migration so we could ease the user base to the 2010 (v4) environment one site collection at a time.

    When we deployed the 2007 master page and theme to the 2010 environment, it wasn’t showing up as an optional master page in the drop down of the Master Page Settings. This was because SharePoint considered it a version 4 (v4) master page instead of a version 3 (v3) master page.

    Of course, I searched online for two days with no viable solution. Evidently, the answer was VERY simple (as it usually is)…

    1)      Go to Site Settings > Modify All Site Settings

    2)      Under Galleries, go to Master pages and page layouts.

     

     

    3) Locate your custom master page and edit it’s properties.

     

    4) Change the check box from 4 to 3.

    5)      Save

    It should now be available as an optional master page in the Master Page Settings of Look and Feel.



  • SharePoint WSS 3.0 Migration Process to Sharepoint 2010 Foundations

    With the newly released SharePoint 2010. I had an excellent opportunity to get approval to migrate to the new environment. I wanted to utilize the new features available for future projects that I have been developing in preparation.

    The environment I’m moving, consists of about 110 subsites in one site collection. A single app/front end server attached to a stand alone SQL server. The content database is approximately 4 gigs. So, all in all, a quite small environment. But it is the focal point for collaboration for the company. customized fairly extensively to meet the needs of the different departments. Also, it has been pushed out in group policy as all 14,000 employees’ home pages. Obviously, this migration has to be performed smoothly and quickly. Below is a detailed process I developed while planning the migration. Also, I included a development (2nd tier) server to move the WSS 3.0 environment to in order to clean it up before the migration.

    I have to say first off, that the pre-upgrade check failed. But a detailed analysis showed the features that failed, were not going to be used in the new environment. So that in itself would not have proved the migration process a failure, but would cause the pages they were used on, to show as unavailable or broken. The catch with plugins is that even if they are uninstalled and removed from the original environment, the feature reference will remain within the default.aspx pages they were used on in a site by site basis. After migration, the default.aspx pages can be accessed in SharePoint Designer 2010 and opened in advanced mode. From there the feature references can be removed.

    Pre-upgrade Preparation
    Communication regarding the migration is going to be essential to the success of the project. Without the assistance of the end users, you will find you will probably have more functionality and process bugs than you can handle at one time. As this update comes with a significant visual upgrade, putting your SharePoint’s best foot forward is essential. You will want the migration to be as pain free as possible for the end users. Help them know what to expect as this is a new roll out.

    Step1
    Discuss with Designers, the purpose of migration, new functionality and their required cooperation with the sites they are responsible for, to assist in locating issues on their sites.
    Step 2
    Migrate the site over to Foundations and test navigation & functionality.
    Step 3
    Resolve breaks on front end servers.

    Upgrade Preparation

    Step 1
    STSADM-backup site collection from production environment.
    Step 2
    Xcopy .dat file to WSS 3.0 development server.
    Step 3
    STSADM-restore site collection to development server.
    Step 4
    Remove custom web parts and customizations that are incompatible with Foundations.
    Step 5
    SharePoint Designer 2007 – default.aspx – remove 3rd party web part references from the master default.aspx file of sites that have been modified by the webpart.

    Anonymous Access
    If anonymous access has been enabled on the original production environment and needs to be receded, it would be a preferable practice to disable this feature on the development server before the step of restoring the site to the development server in the migration process. Once anonymous access is disabled, it will automatically remove the access to all sites configured for anonymous access.

    Step 1
    Disable anonymous access within Central Administration and set permissions on top level site to have domain users as read only users.
    (done automatically on the move to the dev server as Anonymous is already disabled.)
    Step 2
    Set all sites that originally had Anonymous access to a read only Active Directory security group such as “SP_Read”.
    (There will be spots that will be missed as there are detached subsites that will have had anonymous access calendars, etc. Will need to coordinate with Content Admins to have them verify their site is fully functional)

    Migration
    After the restore to the development server has been complete and resolving any inconsistencies in the WSS 3.0 environment, the migration process can occur.

    Step 1
    Stop and detach the WSS 3.0 content database of development SharePoint environment in SQL Server.
    Step 2
    Xcopy database & log files to BI SQL Server.
    Step 3
    Attach WSS 3.0 database to BI SQL Server.
    Step 4
    Create web application in central admin on new production server.
    If already exists, delete existing content database within Central Admin.
    Step 5
    In PowerShell, perform a test migration to verify the database move & check log with following TEST script:
    test-spcontentdatabase -name corp-srce-dev-migration -webapplication http://newserverapplication/ >c:results.txt
    Step 6
    Mount Database to Web Application with the following script:
    mount-spcontentdatabase corp-srce-dev-migration -databaseserver corp-bi-sql2 -webapplication http://newserverapplication

    Navigation
    The WSS/Foundations environment does not have masterpage/navigation hierarchies inherent by default, because of this, the top global navigation bar is not by default configured as a universal navigation bar. This will need to be manipulated within the default.master and/or v4.master pages within the 14 hive. The default master pages are located here: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATEGLOBAL*.master
    Step 1
    Modify current master page to include new navigation properties.

    Visual “4” Upgrade
    Due to WSS site templates not being inherent of the parent pages, they will have to be visually upgraded individually. When I performed the migration, the v4.master file was not put into the master page _catalog folders on each site. This will have to be copied in manually. To complete this process, the following steps must be followed:
    Step 1
    In SharePoint Designer 2010, copy the v4.master page into the _catalog folder of the site.
    Step 2
    View site within browser and set v4 view as permanent by setting visual up grade as permanent in site settings.



  • WSS 3.0 – Make an Uneditable Zone.

    I was given the task of figuring out how to lock down the contents of a Content Editor Web Part. On the top level of every subsite, we have a CEWP that states “For inquiries about content on this page, please contact this page’s Content Administrator: Name.” Whenever a site moderator goes and adds a new web part, it pushed this blurb down the page and the user can delete it all together. If they felt like it. Since a CEWP is not a data list or refrenced website, it will by default inherit the permissions of the parent site. So you cannot apply permissions to it in general within Sharepoint.

    The easy work around to this is to create a new Web Part Zone in the default.aspx and customize the configuration of it within Designer.

      See Link Below



    Lock Permissions to a Zone



  • WSS v3 – Calendar – Forcing More Than 3 Events Per Day

    For those that are just too lazy to press the “Expand All” button above a SharePoint calendar, there is an easy way to set the default to a higher number. The calendar only shows 3 events per day before you have to click on the expand arrows, you can however change this number by modifying a section of the DefaultTemplates.ascx file located in:

    C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATECONTROLTEMPLATES

    Before you make any changes to this file make sure you take a copy of it in case you make any mistakes.

    Within this section you’ll find a declaration
    for the MonthlyCalendarView which should look like this:

    ExpandedWeeks=’<%# SPHttpUtility.HtmlEncode( DataBinder.Eval(Container,"ExpandedWeeks","")) %>‘
    ItemTemplateName=”CalendarViewMonthItemTemplate”
    ItemAllDayTemplateName=”CalendarViewMonthItemAllDayTemplate”
    ItemMultiDayTemplateName=”CalendarViewMonthItemMultiDayTemplate”
    TabIndex=2
    MaxVisibleEvents=10
    >

    Once you’ve made the change to the file & saved it you’ll need to do an IISReset for it to take effect.



  • WSS v3 – Custom Theme.css Refrenced By One Source!

    One of the major drawbacks of SharePoint themes is you have to reapply the theme to any site that uses your custom theme in order to see any new changes that you have made.  This happens because when you apply a theme to a SharePoint site, a copy of the theme is added for the site in the content database. 

    Try it out, open a test site in SharePoint Designer and look at the folder structure in the Folder List task pane.  If you have already applied a theme to this site, you will see a _theme folder. If you have not applied a theme to this site, then this folder will not appear.  Expand the folder and you will see a single sub folder named the same as your theme.  Now go and change the theme the site uses through a browser.  Return to SharePoint Designer and hit F5 to refresh the Folder List.   The _theme folder will appear if you didn’t have a theme applied the first time, and the sub folder under this directory will change to reflect the theme you just applied.

    When you make a change to the theme files on the web server, it does not update any copies of the theme that live in the content database.  When you apply a new theme in the browser, it replaces the copy in the content database with a new theme.  That is why you have to physically reapply a theme when you make changes, you have to replace the theme copy in the content database.

    From a development perspective, the theme copy in the content database is rather handy.  If you update any of the files in the content database (by changing the CSS files in SharePoint Designer and importing in new images), the changes automatically appear in the browser. Woo-hoo! This just made life easier when it comes to developing themes.

    But after you finish up development, you are stuck back with the problem of how to update your theme in the future, especially if it is applied to several sites.  This is where this trick comes in.

    Import CSS to Create Editable Themes

    Create a copy of the final theme.css file and store it in another location on the web server, such as:
    C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATELAYOUTS1033STYLESYOURCUSTOMFOLDERHERE
    You can even rename the file, it no longer needs to be named theme.css.

    Open the original theme.css file in the custom theme folder, delete out all of the contents, and add an import rule for your new CSS file:
    @import “/_layouts/1033/styles/YOURCUSTOMFOLDERHERE/theme.css”;

    Save the file and deploy your theme (add text to SPTHEMES.xml and reset IIS).   Apply your new theme to the site.  Now go to the new CSS file in the Styles folder and make a change.   Refresh your browser.  Your change will appear.  That is cool.

    By moving around your files and using the import rule  you can create a theme that you can update without reapplying the theme to every site that uses it.  Be sure to update your image paths in your CSS styles to a location where you can edit the images as well, such as:
    C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEIMAGESYOURCUSTOMFOLDERHERE 

    Below are a couple of screen shots for the end result of this method.

    View of the file structure on the web server

    ImportThemeFileStructure_orig







































    View of the theme folder and the theme.css file that is still in the theme folder

    ImportThemeCSSView
    Thanks to Heather Solomon and her awesome customization skills!