Posted on:
Categories: SharePoint
Description:
Just compile a taxonomy of organizational units in the SharePoint term store. What’s so difficult about that? A challenge with taxonomies is that different stakeholders need them arranged in different ways. What seems like one taxonomy is often actually several different arrangements of the same basic elements Sites by Geography, Sites by Business Unit, Sites by Department, and so on. Information workers need taxonomies that usefully categorize their information in the context of their role in the organization, so we give them each what they need and, next thing we know, we have 5 taxonomies that are similar but not the same. Then the head honcho walks in and says “I want a dashboard/workflow/search/integration that operates by site. You folk have been categorizing all this information by site, right?” Uh ... well ... yes, but I’m afraid the system has 5 different notions of site. Principle Here's a text book nugget that Information Systems students learn. I am still frequently amazed by its far-reaching consequences in large organizations. Honouring this principle empowers the use of information in flexible ways. Neglect it and bad things will happen downstream. Practice I'd like to put forward the following as a SharePoint good practice that can help to retain flexibility without sacrificing integrity. Maintain base term sets that lend themselves to re-use These term sets are simple but serious. Examples Flat term sets of company locations, commodities, products, customers. They should be kept uncontroversial in nature – avoid arranging them into hierarchies unless those hierarchies are obvious to all stakeholders. Place these in well locked-down term groups. Good maintenance is a big deal. They should correspond to the organization’s master lists. The maintainers should respect the authoritative sources and keep the term sets aligned with them. Automation can help but someone who cares is the key. Compose variant taxonomies from those base lists These taxonomies are much more flexible. Variety is cool. Make use of SharePoint’s re-use and pinning facilities. Site Xyz can be re-used in 3 different term sets, each in a hierarchy that makes sense for their context. Compose the perspectives the organization needs, from the trusted building blocks. Here is a fictitious but practical example. Conclusion This way, the identity of the terms is preserved regardless of where they are consumed. You can rest easy knowing that as content is tagged across your SharePoint landscape, using different taxonomies, common real-world things can still be reliably recognized.




Posted on:
Categories: SharePoint;PowerShell
Description:
Tuning SharePoint Workflow Engine Please read though the following articles then come back here http//www.synergyonline.com/Blog/Lists/Posts/Post.aspx?ID=224 http//msdn.microsoft.com/en-us/library/dd441390(v=office.12).aspx#WorkflowScalabilityPerformance_HardwareSoftwareConfig http//technet.microsoft.com/en-us/library/gg508755.aspx Summary In summary, SharePoint attempts to run Workflows synchronously under the w3wp process, when the number of workflows exceeds 15 per content database, they are converted to SPWorkItems and queued. This queue is then handled by the “job-workflow” Timer Job, which runs every 5 minutes by default. The “job-wofklow” Timer Job is ran by SharePoint Timer Service and only runs on Servers which have the “Microsoft SharePoint Foundation Workflow Timer Service” running. Tuning The configuration options are below Throttle The number of workflows that can be processed concurrently per content database. Default 15 Change using "Set-SPFarmConfig –WorkflowPostponeThreshold 20" Batch Size The number of SPWorkItems that the “job-workflow” Timer Job will attempt to complete in one run. Default 100 Change using "Set-SPFarmConfig –WorkflowBatchSize 200" Timeout How long the job-workflow Timer Job has to complete its batch before it is forcibly shut down. Default 5 mins Change using "Set-SPFarmConfig –WorkflowEventDeliveryTimeout 20" Workflow Timer Interval How frequently the job-worflow Timer Job runs. Default 5 mins Change using "Set-SPTimerJob –Identity job-workflow -Schedule "Every 2 minutes between 0 and 59"" Workflow Timer Instances How many servers run the “Microsoft SharePoint Foundation Workflow Timer Service”, this service run the “job-workflow” Timer Job. Default Each Web Front End (Running on non WFEs requires extra configuration) Change using Central Administration > Manage Service on Server Note This Service can only run on servers which also host the “Microsoft SharePoint Web Application Service” by default. In order for this service to run on Application servers you must create a script that calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a front-end server. http//support.microsoft.com/kb/2674684?wa=wsignin1.0 Monitoring Microsoft doesn’t provide any guidance around when the above options should be changed. Furthermore, they don’t provide any tools which show how taxed the Workflow Infrastructure is. The most common scenario would be that your users are complaining about workflows taking too long to start and/or complete. We have written a script which will show the count of each Workflow queue per content database. The script can be found HERE The queue which we are mostly concerned with is the WorkItemHostType. The script will also show WorkflowTaskType, WorkflowFailover, WorkflowTimerType and WorkflowAutoCleanType queues. Sample script output Tuning Use the script above to monitor the WorkItemHostType count. If the count is constantly at 100, it means that the queue is very saturated. Start tuning by making sure that the Workflow Timer Service is running on all Web Front End Servers. Next, try increasing the Batch Size and monitor the outcome. If that doesn’t solve the issue, increasing the Throttle should help. However, note that this may cause some end user performance degradation as the w3wp worker processes will be processing more workflows. If all else fails, it may be time to add some more resources or servers to your farm. If you have any questions please leave a comment. Enjoy!




Posted on:
Categories: Business;Office 365
Description:
March is 'Office 365-month' at Softlanding! We are hosting Office 365 events (register here), writing blogs and offering free trials (click here to trial). Most people have heard about Office 365, but it can be a confusing offering. Which plan should you choose? Does Lync include PSTN voice? Can I use the Exchange Unified Messaging role in the cloud? These are just some of the questions I have heard over the last several months. I'm writing this blog post to answer some of these questions. Office 365, what is it? Microsoft offers a subscription-based service for its Office products and the corresponding server products; Exchange, SharePoint and Lync. Instead of purchasing the software and installing it on servers, companies subscribe to the products and rely on Microsoft to maintain and upgrade the software. Microsoft has been offering consumer subscription-based services like Hotmail, MSN and Xbox Live for years. Businesses can leverage Office 365, CRM Online and Windows Intune to offer software like Outlook, Lync, Windows, and Word to their employees - this is referred to as Software as a Service (SaaS). Advantages of Office 365 One of the advantages is that you are always using the latest version of the software. Microsoft takes care of upgrading the server software and clients can install new software using 'Click-to-Run'. Office 365 is already on the 2013 versions of Exchange, SharePoint, Lync and Office. Another advantage is the way you pay for the service the CAPEX vs OPEX debate is not one that I get overly excited about, but accountants like it and it does make sense in certain scenarios to pay for software on a monthly basis (OPEX) instead of purchasing hardware and software upfront (CAPEX). Companies that are in an acquisition mode, can take advantage of the easy of deployment. It can take weeks to plan for and deploy new servers; Office 365 can make onboarding of new offices and users relatively quick. Office 365 Choices If you decide to 'move to the cloud', you can do it in phases. Most companies start out with Exchange Online, which is just one component of Office 365. Softlanding has helped companies move existing mailboxes to Exchange Online, developed trials and Proof of Concept projects and provided training for end-users and IT administrators. You can add Lync to complement Exchange with Instant Messaging and Presence, SharePoint to create a portal for employees or host your company website, and subscribe to the latest version of Office. You can bundle some or all of the components, for example you can subscribe to the Small Business Plan for $6.20 per month per user, which includes Exchange, Web Conferencing, a public website and Office Web Apps to create and edit Office files via a web browser. You can add a subscription to Microsoft Office for under $10 per user per month; this allows you to download and run desktop versions of Word, Excel, PowerPoint, OneNote, Access, Publisher and Lync. In my opinion, it is the best way to purchase software for any small business. There are several other packages available for larger organizations, including options that allow for Active Directory integration, intranet sites and full PBX-replacements with Lync on-premise and leveraging the Exchange Unified Messaging role in the cloud for voicemail! Minor limitations of Office 365 Office 365 is a multi-tenant environment, which means that a single instance of the software runs on a cluster of servers, serving multiple tenants. Data is virtually partitioned and each instance is unique and secure but it does limit some forms of customization. If a company has very specific customization needs, Office 365 might not be the right choice. Office 365 provides the latest version of software, which sometimes is not desirable. For example, if a specific version of Word is required to work the company's ERP system, it might not be possible to move the Office applications to Office 365. A third reason could be the US Patriot Act. Canada has enacted strict privacy laws (PIPEDA) that companies need to comply with. The Office 365 datacenters are located in the US (and other places in the world, but not Canada). However, in our experience deploying customers to the Office 365 cloud, this has not been a show-stopper. Give Office 365 a test-drive Office 365 is one of the easiest ways to move to a cloud-services model. You always run the latest version of the software, without having to worry about maintenance and upgrades. Financially, the Total Cost of Ownership and OPEX vs CAPEX calculations are often more favorable when comparing Office 365 to the on-premise alternatives.If you’re interested in Office 365, why not give it a try? I encourage you to sign-up for a no obligation trial here http//tinyurl.com/o365canada this link gives you the option of trying Office 365 for 30-days, for up to 25 users. As an alternative, you can attend an in-person demo of the Office 365 and its capabilities by attending one of our Customer Immersion Experience sessions at the Microsoft office in Vancouver.




Posted on:
Categories: SharePoint
Description:
We have a client who requires a custom Layout Page with several WebPart Zones and two Publishing Zones. Unlike Web Part Zones, you can't simply keep adding them to the page. I did a quick Google search to see if I could find some more information on how to do this. Most of the results were about adding more than one WebPart Zone to a custom Layout Page, which I already know how to do. I did find a good blog on how to create a Page Layout based on a custom Content Type so I used this as a starting point Create Page Layout based on custom Content Type in Visual Studio 2010 This solution wasn't exactly what I needed and it included the use of a handy Visual Studio tool which worked great for Visual Studio 2010 but we're using 2012. So with some modifications, here's how to create a custom Page Layout with more than one Publishing Zone. The solution is a 3-step process Create a custom Content Type Create a Layout Page based on the Content Type Open VS 2012 and create a new SharePoint Project Add a new Site Column using the HTML Type. I called mine FooterContent. The element file should look something like this <Elements xmlns="http//schemas.microsoft.com/sharepoint/"> <Field ID="63d7cf7e-9bb6-4ffe-8ccf-8c2c9a85cbc5" Name="FooterContent" DisplayName="Footer Content" Type="HTML" Required="FALSE" Group="Custom Site Columns"> </Field> </Elements> Now create a new Content Type. I called mine CustomLayoutPageContentType and inherited from Page (mostly because those were the instructions from the blog I was following. In order to use the custom tool, the content type had to be based on Page. In the Content Type tab I elected to no inherit from the parent Content Type as I don't need any of those columns. Your elements file should look something like this <?xml version="1.0" encoding="utf-8"?> <Elements xmlns="http//schemas.microsoft.com/sharepoint/"> <!-- Parent ContentType Page (0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39) --> <ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39008EC5D36E00CA445CA91BC2347378F5C5" Name="CustomLayoutPageContentType" Group="Custom Content Types" Description="Use this content type for the Custom Layout Page" Inherits="FALSE" Version="0"> <FieldRefs> <FieldRef ID="63d7cf7e-9bb6-4ffe-8ccf-8c2c9a85cbc5" DisplayName="Footer Content" Required="FALSE" Name="FooterContent" /> </FieldRefs> </ContentType> </Elements> Now create your custom layout page. I did this by adding a Module and adding my layout page to the module. Here's a basic layout page where I've added a WebPart Zone followed by my custom content <%@ Page Language="C#" Inherits="Microsoft.SharePoint.Publishing.PublishingLayoutPage,Microsoft.SharePoint.Publishing,Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" metaprogid="SharePoint.WebPartPage.Document" metawebpartpageexpansion="full" %> <%@ Register TagPrefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register TagPrefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register TagPrefix="PublishingWebControls" Namespace="Microsoft.SharePoint.Publishing.WebControls" Assembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <aspContent ContentPlaceholderID="PlaceHolderPageTitle" runat="server"> <SharePointWebControlsFieldValue id="PageTitle" FieldName="Title" runat="server" /> </aspContent> <aspContent ContentPlaceholderID="PlaceHolderMain" runat="server"> <div class="webpart-zone"> <WebPartPagesWebPartZone runat="server" Title="Web Part Zone" ID="Zone1" /> </div> <div class="publishing-zone"> <PublishingWebControlsRichHtmlField ID="RichHtmlField1" FieldName="FooterContent" runat="server" HasInitialFocus="True" MinimumEditHeight="200px" /> </div> </aspContent> Now go back to your Elements.xml file for your Page Module. You need to associate your custom page layout with your custom content type. You do this by adding a PublishingAssociatedContentType <Property Name="PublishingAssociatedContentType" Value=";#CustomLayoutPageContentType ;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39008EC5D36E00CA445CA91BC2347378F5C5" /> Where the Value includes the name of your content type followed by the GUID (which you can grab from the Elements file of your Content Type. Your elements file should look something like this <Elements xmlns="http//schemas.microsoft.com/sharepoint/"> <Module Name="PageModule" Url="_catalogs/masterpage"> <File Path="PageModule\CustomLayoutPage.aspx" Url="CustomLayoutPage.aspx" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE"> <Property Name="Title" Value="Custom Page Layout" /> <Property Name="MasterPageDescription" Value="Custom Page Layout"/> <Property Name="ContentType" Value="CustomLayoutPageContentType" /> <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resourcescore,Culture;/Preview Images/WelcomeSplash.png, ~SiteCollection/_catalogs/masterpage/$Resourcescore,Culture;/Preview Images/WelcomeSplash.png" /> <Property Name="PublishingAssociatedContentType" Value=";#CustomLayoutPageContentType ;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39008EC5D36E00CA445CA91BC2347378F5C5";# /> </File> </Module> </Elements> Deploy your Solution. You can verify that your custom site column and content type were deployed by navigating to the Site Columns page and the Content Types pages through the Site Actions menu. You can verify that your layout page was deployed to the Master Page Gallery and note that the proper Associated Content Type was applied. Now you can go ahead and use your custom Page Layout And that's it. Of course you will note that in this example I still have only 1 Publishing Zone on my page. To add another one you can either repeat the process, adding a new custom column to your content type or you can add the standard Publishing Web Control... <PublishingWebControlsRichHtmlField ID="RichHtmlField2" FieldName="PublishingPageContent" HasInitialFocus="True" MinimumEditHeight="100px" runat="server"/>




Posted on:
Categories: SharePoint
Description:
Reuse of XSL in SharePoint 2013 After the big push towards search-based rollup web parts in SharePoint 2013 (namely, the Content Search web part) and their associated display templates, there hasn't been a lot of noise regarding how "old fashioned" Content Queries work with regards to styling. It turns out, SharePoint 2013 Content Query web parts are nearly identical to SharePoint 2010. This means, among other things, it still uses XSL to format and display information retrieved by the query. Initially I was dissapointed to learn that I could not use my newly designed display templates with content queries, but then I realized this could be a huge benefit to clients with many custom styles upgrading from SharePoint 2010. This means that instead of writing many new html/javascript-based display templates to replace their original XSL, we can simply transplant their 2010 XSL styles directly in to 2013, with little or no changes. Identical Web Part Settings As you can see above, apart from the global 2013 branding changes, the web part settings are identical. In particular, take a look at the Styles section - it's the same! So not only can you use your 2010 XSL styles, but you can carry over all your web part settings. Although we cannot take advantage of the cross-site data retrieval that the Content Search web part brings to the table, you can bring forward all (or most, let me know if there are differences I haven't noticed yet) your carefully designed content query web parts directly into 2013 from 2010 with minimal changes.