Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
EPL Standings
 
 
Windows Server

Sharepoint 2013 : Service Application Fundamentals (part 3) - Connecting Across Farms

- 2015 Chevrolet Camaro Z28 - The Legend Returns
- Wagon Audi Allroad Vs. Subaru Outback
- 996 Carrera 4S is Driving Perfection
3/24/2014 1:41:16 AM

2. Connecting Across Farms

Once you understand the service applications and all their proxies in your farm, the next logical step is to add more connections. Some service applications are capable of being published and then consumed across different SharePoint farms. Even more impressive is the fact that none of the service applications except the User Profile service application require the two SharePoint farms to be in trusted active directory domains. In fact, a SharePoint 2010 farm can even consume services from a SharePoint 2013 farm, though this capability is limited to the service applications and features available in SharePoint 2010, of course. For example, SharePoint 2010 can’t consume the App Management service from SharePoint 2013.

Before you can publish or consume the service applications between two farms, you have to establish a farm trust, which is done by using the SharePoint Management Shell to create and register certificates between the two farms.

After the farm trust is configured, you can access the publishing farm and select the service application you want to publish. Once it is published, you get a URL for accessing the published service.

From the consuming farm, you simply connect to the published service by providing the URL. Then the connected service application can be added to a service application group, and it will provide services just as if the service application were part of the farm. Figure 5 shows an example of four farms at work.

FIGURE 5

image

Farm 1 introduces a concept that hasn’t been discussed yet: the enterprise services farm. The enterprise services farm highlights the advantage of the service application architecture over the monolithic SSP model. Typically used only in large companies, this type of farm is created and maintained exclusively to provide services to other SharePoint farms throughout the organization. This way, the services farm can be optimized for hosting services and can be maintained in the same manner. For example, a Search index might contain several million items, requiring several days to do a full crawl, and hours to do an incremental crawl. In order to do this efficiently, you need to optimize your hardware for Search. If you have three SharePoint farms and each maintains its own Search service application, it would be very expensive to do a lot of repetitive crawling of content. Instead, a much better solution would be to maintain the index in one farm and just consume the service from the other farms.

Farm 2 is a simple farm for publishing content, maybe hosting just informational websites or similar content. In this farm, the demand for service applications is low, and all the service applications it does require are provided by the enterprise farm. Therefore, this farm actually has no local service applications and is just optimized for displaying SharePoint content.

Farm 3 is a collaboration farm, and a busy place. This farm has demands for all types of service applications — some are consumed from farm 1, and others are hosted locally. The locally hosted service applications are those not capable of being published across farms, so they must reside in the farm where they are needed. Note that the Managed Metadata service application from farm 4 is being consumed. Other than that, there is nothing special about this scenario other than the flexibility of consuming service applications from multiple farms.

Farm 4 is very similar to the collaboration farm in terms of purpose. It is hosting its own web applications and consuming local and remote service applications. Additionally, it has published the Managed Metadata service application for consumption by farm 3. Although all three farms are using the default group in this example, this isn’t a requirement. You very well could have configured the [custom] group in any of the farms to consume the cross-farm service applications.

Service Applications As a Framework

You have probably noticed by now that all the service applications act slightly different. This is because service applications are really a collection of individual services built to plug into a framework. The advantage of this framework is that anyone can plug into it. Third-party vendors and developers can use it to add their functionality to SharePoint 2013 just as they did with SharePoint 2010; but instead of needing to create a custom third-party application to administer their added SharePoint functionality, developers just plug right into Central Administration, providing administrators with a consistent experience. From an administrator’s perspective, there is no difference between these service applications and one provided out of the box with SharePoint 2013.

Top Search -----------------
- Windows Server 2008 R2 : Work with RAID Volumes - Understand RAID Levels & Implement RAID
- Windows Server 2008 R2 Administration : Managing Printers with the Print Management Console
- Configuring Email Settings in Windows Small Business Server 2011
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Implement Permissions
- Monitoring Exchange Server 2010 : Monitoring Mail Flow
- Windows Server 2008 R2 :Task Scheduler
- Windows Server 2008 R2 : File Server Resource Manager
- Windows Server 2008 R2 : Installing DFS
- Exchange Server 2010 : Managing Anti-Spam and Antivirus Countermeasures
- Windows Server 2008 R2 : Configuring Folder Security, Access, and Replication - Share Folders
Other -----------------
- Sharepoint 2013 : Understanding Service Applications - A History of Service Applications in SharePoint
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 5) - Migrating Computer Accounts
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 4) - Migrating User Accounts
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 3) - Migrating Groups
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 2) - Installing a Password Migration DLL on the Source Domain
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 1) - Modifying Default Domain Policy on the Target Domain
- Microsoft Exchange Server 2007 : Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect (part 2)
- Microsoft Exchange Server 2007 : Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect (part 1)
- Windows Server 2012 : Provisioning and managing shared storage (part 7) - Managing shared storage - Managing volumes, Managing shares
- Windows Server 2012 : Provisioning and managing shared storage (part 6) - Managing shared storage
 
 
Most view of day
- Microsoft PowerPoint 2010 : Animating Slide Content (part 2) - Special Options for Text Animation
- Windows Server 2008 R2 : Managing Computers with Domain Policies (part 4) - Deploying Printers
- Troubleshooting Network Problems : Repairing a Network Connection
- Microsoft Visio 2010 : Annotating Visio diagrams with issues
- Data Bindings : Give and Take
- Windows Phone 7 : Sensors - Creating a Seismograph
- Using Advanced System Management Tools : Editing the Registry (part 1)
Top 10
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 3) - Email Address Policies - Creating a New Email Address Policy
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 2) - Email Address Policies - Changing an Existing Policy
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 1) - Accepted Domains
- Microsoft Exchange Server 2010 : Basics of Recipient Management - Exchange Recipients
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 7) - Using iSCSI Initiator - Creating volumes
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 6) - Using iSCSI Initiator - Establishing a connection
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 5) - Using iSCSI Initiator - Discovering targets
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 4) - Using iSCSI Initiator - Configuring iSCSI Initiator
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 3) - Configuring iSCSI Target Server - Creating iSCSI virtual disks
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 2) - Configuring iSCSI Target Server - Installing the iSCSI Target Server role
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro