Hey! Should I install this SharePoint patch?

I get this question all the time, so I thought I’d save us both a lot of time and write it down in a blog post. I maintain a list of SharePoint 2010 patches and SharePoint 2013 patches. These make for an easy way for SharePoint administrators to keep up with the latest patches for their favorite flavor of SharePoint. Because of this I get a lot of questions about whether someone should install a specific patch or not. I’ll try to answer that question here.
The answer to “Should I install this SharePoint patch” depends a lot on the type of patch we’re talking about. Because of that I’ve broken the next part down by patch type.

Hotfix or Critical On Demand (COD)

What is it?

A hotfix or COD patch is a patch that is critical and can’t wait for a Cumulative Update or Service Pack. It might be security fix, or it might be a functionality fix. It’s issued as a one-off fix for an issue. Often it’s suggested to a customer by Microsoft PSS after troubleshooting an issue. A hotfix may contain fixes for one or more components in SharePoint.

Should I install it?

If PSS recommends a hotfix to fix your issue, you should consider installing it. If possible, install it in a test environment where you can reproduce the issue to verify that it fixes it. PSS has smart people, but SharePoint is a complicated beast and you shouldn’t install any patches that don’t fix anything.
If you hear about this hotfix from some place other than PSS be very careful. Only install a hotfix if it fixes an issue you’re currently experiencing and it’s a high profile problem. Hotfixes aren’t tested very thoroughly so they present a risk when installed. They might fix one issue, but they could cause another one. If you’re considering installing a hotfix install it in a test environment first and kick the tires a bit to make sure the cure isn’t worse than the illness. You cannot uninstall any SharePoint patches, so be very sure you want this patch on your farm as they’re mated for life once you install it.

Cumulative Update (CU)

What is it?

Cumulative Updates (CUs) come out every even numbered month; February, April, June, etc. They contain all the patches from the previous CUs since the last major patch (RTM or Service Pack) and all the hotfixes released since then. The “cumulative” part means if you install the August 2012 CU you don’t need install the June 2012 CU first. CUs are also cumulative in the sense that the SharePoint Server patch includes the patches for SharePoint Foundation. The Project Server CU includes the SharePoint Server and SharePoint Foundation patches as well. You only need to install the CU for the product you have. This is a welcome change from SharePoint 2007 where we had to stack the patches. Also, CUs contains the patches for all the supported languages which is why they’re so large. If you have a language pack installed, its binaries are also patched by the CU. When it works, you can also slipstream CUs into your install media to reduce your installation time.

Should I install it?

Each CU comes with a Knowledge Base article that describes the fixes in it. You should only consider installing a CU if you can point at a fix in that KB article that your farm needs. If it doesn’t offer any fixes you need, you should pass on it. If it does fix something that is plaguing your farm, then install the CU in a test environment to verify the fix. You should also poke around the test environment to see if everything else still works. CUs often contain Regressions. A Regression is when something that used to work doesn’t work anymore. The software has regressed. And speaking of Regressions, CUs are chock full of them. At least three SharePoint 2010 CUs were pulled because the Regressions were so bad. For instance, the April 2012 CU for SharePoint 2010, was out for a full month before it was pulled. Remember, you cannot uninstall any SharePoint patches, so if you get all antsy and install a CU without testing it first and it breaks something, you’re stuck with it.

Public Update (PU?)

What is it?

This is kind of a weird one. In March of 2013, Microsoft released the first Public Update I’ve ever seen. It was for SharePoint 2013. This patch is a cross between a Cumulative Update and a Service Pack. Microsoft announced they consider the March 2013 PU to be the baseline for SharePoint 2013

Should I install it?

Yes. Along with saying they consider the March 2013 PU the baseline for SharePoint 2013, they also said that all subsequent patches will require it. That means to install any CUs or SPs after it, you’ll need to have the March 2013 PU installed. So install it in your test environment, test it for 30 days, then install it in your Production environment.

Service Pack (SP)

What is it?

The big daddy of the SharePoint patches, the Service Pack. Service Packs are contain all the patches that come before them. They are a major patch release. They go through months of testing before they are released and sometimes have beta releases. Service Packs are also language specific. The service pack’s language needs to match SharePoint’s installed language.  Language packs also have separate service packs.

Should I install it?

Yes. Service Packs are important milestones and you should plan to install them into your farms. Of course you should always install them into a test environment first since you cannot uninstall any SharePoint patches. After you and your users have tested the Service Packed for a minimum of a month you should plan a planned outage and install it in your Production environment. If you have any language packs installed, remember to install the service pack for the language packs too.

Hopefully that helps you decide whether to inflict a patch on your SharePoint farm.
tk
ShortURL: http://www.toddklindt.com/ShouldIInstallPatch

Reference:

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=433
 

SharePoint 2010 Administration - Backup and Restore

Introduction

In this article we can explore the backup and restore operations inside SharePoint. For Administration tasks we need to use the SharePoint Central Administration web site which is accessible from the Start menu, as shown below.

Following are the most common administrative tasks:

• Backup and Restore
• Site Usage Analysis
• Cleaning up Unused Sites
• Managing the Search Service
• Managing Quotas and Locks

Backup

We can perform different levels of backup inside SharePoint 2010. The levels include:

• Farm Backup
• Site Collection Backup
• Site Backup
• Web Application Backup
• List Backup
• Library Backup
• Solution Package Backup
• Configuration Backup
• Content Database Backup

The types of Backup are:

1. Full Backup
2. Differential Backup
3. Incremental Backup

We can have automated backup strategies to backup the required contents on intervals.
The Backup and Restore settings can be accessed from SharePoint Central Administration.

For performing a manual backup, use the Perform a backup link shown above. In the appearing page, select the items you need to backup and click the Next button. Depending on the item the backup size will increase.

In the next page of the backup wizard, enter the backup type and location as shown below.

Click the Start Backup button to perform the backup. Make sure you set the location shared access to Everyone. 

The above screen shows that your backup operation is running. Wait for a few while to complete the operation. After the operation, you will get a report as shown below.

Note

If the Backup page says the Administrative service is not running, you need to start it manually from Windows Services.
Use the Run window to execute the command services.msc. In the appearing applet, right click and start the SharePoint 2010 Administration service.

Restore

We can restore a farm, site, or the backed up item using the Restore from a backup option.

In the appearing page select the radio button of the appropriate backup and click the Next button.

You can see that the backup location is remembered automatically. In real world scenarios we have to choose different backup locations.
In the next page select the components to restore.

Click the Next button and the restore operation gets started.

Summary

In this article we have explored the common administrative tasks inside SharePoint. Please note that the Backup and Restore operation can be performed programmatically too.

Reference:

http://www.codeproject.com/Tips/419745/SharePoint-Administration-Backup-and-Restore

Configuring outgoing email in SharePoint 2010 with Exchange 2010 – Step by Step Guide

144

In my last article I provided you with a guide in setting up your SharePoint 2010 farm providing it with the capabilities in receiving incoming email which can then be delivered directly to your SharePoint libraries and or lists.  Today we wrap up our 2 part series on email flow in SharePoint 2010 in which I will provide you with another step by step guide in configuring your SharePoint Farm in order for it to send outgoing emails through your Microsoft Exchange server.
The environment
This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

SharePoint 2010 allows you to configure any SMTP service including the one which I had setup in my previous article to send outgoing email, however we will utilise Exchange 2010 (same instructions apply for Exchange 2007) to provide email delivery to our end users.  Instructions on configuring the SMTP service (i.e. you are not using Microsoft Exchange in your environment) can be found on TechNet.
Creating a Receive Connector in Exchange 2010

If you recall from my previous article when we were configuring incoming email, we created a “Send Connector” in Exchange to forward the messages to the SMTP service that we had configured and installed.  This time round we will create a “Receive Connector” in Exchange 2010.
Launch the Exchange Management Console and navigate to Server Configuration / Hub Transport / New Receive Connector.  The New Receive Connector wizard is invoked.
Enter a descriptive name and ensure “Custom” is selected as the intended use.

Click Next
Leave “All Available IPv4” in your Local Network settings unless you have specific Exchange IP requirements.

Click Next
Edit the IP address of your SharePoint 2010 server.

Click Next

Click New
You will now notice that our SharePoint 2010 Outgoing mail connector is listed with our default Exchange 2010 Receive Connectors.. 
We will now venture into its properties and make a minor permission change.  Click on the “Permission Groups” tab and select Anonymous users.

Click Apply.
Configuring outgoing email in SharePoint 2010 Central Administration
Launch Central Administration and navigate to System Settings / E-Mail and Test Messages / Configure outgoing e-mail settings.

Enter your Outbound SMTP server, i.e. your Exchange server where we created our receive connector and specify a From and Reply-to address.

Click OK
Testing our configuration
Lets navigate to our SharePoint 2010 web application and create an Alert .  In my example I will create an immediate alert for Announcements.
Navigate to your Announcement List and click on List Tools/List and then click on “Alert Me” located in the ribbon interface.

Select “Set alert on this list” and select your Alert options.  Ensure that you have “send notifications immediately” selected for testing purposes.


Click OK
You should receive your notification email that you have successfully subscribed soon after creating your alert.

I will now create a Test Announcement to ensure that the actual alert is delivered.

Alas! 5 minutes later (based on the immediate timer job definition schedule) we have received our email alert confirming that our SharePoint configuration with Exchange was successful.

Did you know that you can also configure outgoing email for a specific Web application?  You might want to do this if you have multiple SharePoint Web Applications hosting specific site collections and would want a different From and or Reply Address setup.
Even though we are now going to configure outgoing email for a specific Web application, you are still required to setup the default farm outgoing email settings as per the above.
Configuring outgoing email for a specific Web application in SharePoint 2010 Central Administration
Launch Central Administration / Application Management / Manage Web Applications.
Select one of your Web Applications and then select “General Settings” from the Ribbon.

Select “Outgoing E-Mail” from the drop down.
It will pick up your default farm settings that we entered in earlier in which you can now change the From and Reply-to address to something more specific for the selected Web application.

Click OK
We are done!  I hope you have found this step by step guide in configuring outgoing email in SharePoint 2010 with Exchange useful, and stay tuned as we continue our journey in configuring our SharePoint 2010 Farm.
Subscribe to this blog and join our Facebook page and Twitter Page to keep up to date and be notified of our latest articles.
If you require any assistance with your SharePoint or other IT needs, the team at GKM2 are happy to assist.  You can contact us via info@gkm2.com.au or 1300 797 288 within Australia.
Articles in this series
Installing SharePoint 2010 using Least Privilege Service Accounts – Step by Step Guide
Configuring incoming email in SharePoint 2010 with Exchange – Step by Step Guide
Configuring outgoing email in SharePoint 2010 with Exchange – Step by Step Guide

Reference:

http://sharepointgeorge.com/2010/configuring-outgoing-email-sharepoint-2010/

Configuring incoming email in SharePoint 2010 with Exchange – Step by Step Guide

Today we continue down our journey in setting up our SharePoint 2010 farm, with the focus on configuring incoming email for SharePoint 2010.  When SharePoint 2007 was released, there was a lot of discussion and rumors around Exchange 2007 being the last version of Exchange to provide Public Folder support, and that SharePoint 2007 was going to be it’s alternative. Microsoft quickly changed its stance and continues to support Public folders in Exchange 2010.  However, there still might be a number of compelling reasons why you would want to consider storing incoming email messages in SharePoint 2010 document libraries, instead of public folders.  You can read more about the benefits of using email-enabled SharePoint libraries in one of my article’s here.
In today’s post, I will provide you with a comprehensive step by step guide in configuring your SharePoint 2010 server in conjunction with Exchange 2010, to provide successful delivery of incoming email directly to your SharePoint Web Applications.
The environment
This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

The SMTP service
SharePoint 2010 is reliant on the SMTP service which is a Windows 2008 feature and we must install this on our SharePoint 2010 front-end web server.
Navigate to your Start Menu / Administrative Tools / Server Manager.  Click on the Features node and select Add Feature.  Scroll down and select SMTP Server and click on Add Required Role Services.

Click Next, Next and Install.

Click Close
We now need to install the II 6.0 Management Tools on our Windows 2008 R2 server in order to configure our SMTP service.  If IIS 6.0 Manager is not already installed you must do so via, Start / Administrative Tools / Server Manager.  Click on the Roles node and select Role / Add Role Services.  Then select Management Tools and IIS 6 Management compatibility.  Click Install.
We can now launch the IIS 6 Manager via Start / Administrative Tools.

Right click on SMTP Virtual Server #1 and select properties.
Under the General tab, I have enabled logging and encourage doing so at the start in the event we need to do some troubleshooting.  You can turn logging off after successful testing.

Click on the next tab, “Access”.
Click on “Authentication” and ensure that Anonymous access is selected.

Next, click on “Connection” and ensure “All except the list below” is selected.

Finally, click on “Relay”, and ensure that “Only the list below” is selected and that “Allow all computers which successfully authenticate to relay, regardless of the list above” is also checked.

Now click on the Messages Tab and make any necessary adjustments that you see fit, such as potentially increasing the message size to allow for the delivery of larger emails with attachments into your SharePoint Libraries and Lists.

Next click on the Delivery Tab in which I normally leave all the defaults in place.

We can skip the LDAP routing tab as there are no settings required to be configured in this area.
Lastly, the Security tab should list the default permissions as per the below.  No changes are necessary in this area.

We next journey into the “Domains” are within IIS 6 Manager and a domain name should be listed, which by default is the fully qualified domain name of the machine.
Right click on the Domain Name and select properties and take note of the Drop directory.

Finally, we now just need to confirm that our SMTP service is set to start automatically in the event the server is restarted.  I can tell you now that the service is by default set to Manual.
Venture into Start / Administrative Tools / Services.
Scroll down your list of services and ensure that the Simple Mail Transfer Protocol (SMTP) is set to Start-up type, Automatic.

We have now completed the configuration of our SMTP service on our SharePoint Server.
Exchange 2007/2010 Connectors
Part two of the implementation of configuring incoming email in SharePoint is to configure our connectors in Microsoft Exchange.  Now even though this is not a requirement, most organisations running SharePoint 2010 or 2007 will also be running a recent version of Microsoft Exchange, hopefully either 2007 or 2010.  Exchange 2010 or 2007 will provide you with that extra layer of protection ensuring that all the necessary message hygiene has been performed via its inbuilt Anti Spam Agents on the Edge or Hub Transport Server in conjunction with some form of email antivirus such as Microsoft’s Forefront for Exchange, before the message is delivered to the SharePoint 2010 List or Library.
My instructions and screen captures below are from an Exchange 2010 server which are pretty much identical and applicable to Exchange 2007.
Let’s begin by launching the Exchange Management Console / Organization Configuration / Hub Transport.
Click on Send Connectors / Actions / New Send Connector.
Type in a descriptive name for your Send Connector and then select Internal as the type.

Click Add and enter the Address space as the fully qualified domain name of the server where the SMTP service is installed (i.e. your SharePoint Server)

Click Next
Enter the IP address of the server which also hosts the SMTP service.

Click Next
Select “None” as your smart host authentication settings

Click Next
Ensure your Hub Transport Server has been added.

Click Next

Click New and then click Finish
The end result will be that the Send connector will route email to the SMTP service sitting on our SharePoint Server.

The Directory Management Service

SharePoint 2010 allows you to leverage Active Directory Domain Services (AD DS) so that contacts that are created when you email enable document libraries or lists are stored in a designated Organizational Unit within your AD DS infrastructure.  So why would you want to enable Directory Management Service?  Purely for the fact that by storing these contacts in AD, you are allowing your users to locate email enabled libraries and lists easily from within their Outlook Address book.
Let’s begin by creating an Organizational Unit in Active Directory.
From your Active Directory server, click Start / Administrative Tools / Active Directory Users and Computers.
Right click on your domain object and select New / Organizational Unit
Type in a descriptive name

Click Ok.
The next step is imperative and very important that we get this right.  I have seen on many occasions where incorrect permissions were applied and all sorts of problems were encountered when libraries or list were email enabled.
In summary, we need to provide our Central Administration Application pool identity account specific permissions to our recently created Organizational Unit to be used for creating and deleting contacts for our SharePoint 2010 libraries and lists when they are either email enabled or email disabled.
Right click on the recently created Organizational Unit and click on Delegate Control.  This will invoke the Delegation of Control Wizard.

Click Next.
We will now add the Central Administration application pool account which you can confirm from IIS Manager as per the below screen capture.

Add the necessary Account.

Click Next.
Click Create a custom task to delegate.

Click Next
Click “This folder, existing objects in this folder, and creation of new objects in this folder’.

Click Next
Click on Create All Child Objects and Delete All Child Objects.

Click Finish.
Before we finish off our configuration of AD DS and the Directory Management Service we need to provide our Central Administration application pool account with Delete Subtree permissions.
We need to ensure that “Advanced Features” from within Active Directory Users and Computers (ADUC) is active before we venture into the security tab of our SharePoint organizational unit.  If you do not enable Advanced Features, the security tab will not be visible.
From within ADUC, click on View and select Advanced Features.
Right click on our SharePoint 2010 Organizational Unit and select Properties.
Click on the Security Tab / Advanced /and Edit the CA Application Pool Identity Account.

Select Allow for “Delete Subtree”

Click on OK and Apply.
After assigning these permissions, you must run IISRESET on your SharePoint server.
Configuring Incoming e-mail settings in Central Administration
Navigate to Central Administration / System Settings / Configure incoming e-mail settings.

Select Yes to “Enable site on this server to receive e-mail”
Select “Automatic” for Setting mode.
Select “Yes” to use the SharePoint Directory Management Service to create distributions groups and contacts.
Enter your Active Directory container details, i.e. the Organizational Unit container that we created specifically for our SharePoint 2010 contacts.
Ensure that your SMTP server details are correct, this should be the fully qualified domain name of your SMTP service that was installed on your SharePoint Server.

Finally, ensure “Accept mail from all e-mail servers” is selected.

Click OK.
Please note that this process will configure the necessary permissions on the email drop folder listed in IIS 6 Manager.  In summary, the following permissions are added;
WSS_Admin_WPG – Full Control and
WSS_WPG – Read & Execute / List folder Contents / Read

Ensure that these accounts are added successfully and on the rare occasion in which it isn’t, you will need to add them manually.
Testing the configuration
From within any document library or list, click on Library / Library Settings.



Click on Incoming e-mail settings.
Select “Yes” to allow this document library to receive e-mail.
Select your email attachment options and ensure that Save original e-mail is set to Yes.
Lastly, ensure that you Accept e-mail messages from any sender is selected.

Click OK.
This is your first step to ensure that all of the above configuration is in place.  If you do receive an error, it’s most likely going to be permissions related against your Organizational Unit, i.e. SharePoint may not have the privilege to add the contact in Active Directory.
Let’s navigate back to ADUC and confirm that our “testing” contact is created under the SharePoint 2010 Contacts Organizational Unit.

Let’s next navigate to our Exchange 2010 server and ensure it is also listed there with an SMTP address against it.
Launch your Microsoft Exchange Management console and navigate to Recipient Configuration / Mail contact.

Right click on the Contact and select Properties / E-Mail Addresses.
Ensure that both an internal and external routable email address is listed.

From your favorite email client, send a test email to the document libraries’ external SMTP address.
Navigate to your recently email enabled document library and hopefully after a couple of minutes (SharePoint Job timer service delay) you should have received your test email.

Well! That’s all that is to it, from start to finish.  Apart from sending a test email, there are a couple of other scenarios that you should test to ensure complete seamless integration with the SharePoint 2010 Directory Management Service.  Within the same document library, modify the email address to something different and ensure that this change also flows through to Active Directory. You should also try disabling incoming email from that same library and ensure that the contact is completely removed from Active Directory.  If you pass all of these tests scenarios, then we are comfortable in knowing that the correct delegation was provided to our Central Administration Pool Account against our SharePoint Contacts Organizational Unit.
I hope you have found this step by step guide in configuring incoming email in SharePoint 2010 with Exchange useful, so stay tuned as we continue our journey in configuring our SharePoint 2010 Farm.

Subscribe to this blog and join our Facebook page and Twitter Page to keep up to date and be notified of our latest articles.


Reference:

http://sharepointgeorge.com/2010/configuring-incoming-email-sharepoint-2010/