The server farm account should not be used for other services for User Profile Synchronization Service in SharePoint 2010 Health Analyzer

The User Profile Sync service has to run under the Farm account. But doing this causes a error to appear in the SharePoint 2010 health analyzer.




I use a simple trick to prevent this error from showing in health analyzer without disabling the rule.

Go to Central Administration -> Security -> Configure Service accounts.

Select the User Profile Synchronization Service . You see that it is configured to use the Farm account.



Also the ForeFront Windows Services are running under the Farm account



Select a different managed account. Now click OK.



You will see that one of the ForeFront identity services under your Windows services is now configured to use the chosen account.



Now here is the trick. Go to Central Administration -> System Settings -> Services on server.  Stop the User Profile Sync service if is not stopped. Now start the service again.




As you can see we are now required to use the Farm account. Give the password and click OK. After a while the service will have the state started.
Now go to your Windows Services list. Search for the ForeFront Identity services. As you can see they are configured to use your farm account.



Now go to Central Administration -> Security -> Configure Service accounts. Select the User Profile Synchronization Service . And what do we see? SharePoint hasn’t changed the account
listed here.



Now reanalyze the error in Health Analyzer. The problem is gone.

SharePoint Site Keeps Prompting for Credentials

Problem

 

SharePoint keeps prompting you for credentials in the following scenarios:

1. You get prompted for credentials when you access the site in the browser.
2. You get prompted for credentials when you open a document from SharePoint.
3. You get prompted for credentials after you open a document from SharePoint and try to “Save As”.

Cause

The most likely cause of your problem is that you are using an FQDN for SharePoint (For example, sharepoint.company.com) and your client machine runs Windows 7. By default, Internet Explorer and Webdav assume that this address is on the Internet and as a security measure, does not automatically pass in your credentials.

Solution

If your scenario is the same as above, then you will need to do two things.

1. Add your SharePoint server’s FQDN to your Trusted Sites or Intranet Sites zone.
2. Modify your registry settings for the WebClient service.

Add your SharePoint server’s FQDN to your Trusted Sites or Intranet Sites zone.
If using Trusted sites, ensure that you do not select “Require server verification (https:) for all sites in this zone”.

1. Internet Explorer -> Internet Options -> Security -> Trusted Sites -> Sites
2. Add the URL(s) of your SharePoint server(s).
3. Click OK
4. Click Custom Level -> Scroll to the bottom -> User Authentication
5. Ensure that it is set to Automatic logon with current user name and password

If you are using the Intranet Sites zone, note that you need to manually add the SharePoint server URL under Advanced settings.

1. Internet Explorer -> Internet Options -> Security -> Local Intranet -> Sites -> Advanced
2. Add the URL(s) of your SharePoint server(s).
3. Click OK
4. Click Custom Level -> Scroll to the bottom -> User Authentication
5. Ensure that it is set to Automatic logon with current user name and password

Modify your registry settings for the WebClient service.

1. Open Regedit, Start -> Run -> regedit
2. Browse to the location: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters
3. Create a new Multi-String Value and call it AuthForwardServerList
4. Under Value data: Type in the URL of the SharePoint sites, one on each line. You may use wildcards.
5. Click OK.
6. Open Services console, Start -> Run -> services.msc
7. Look for the WebClient service, and click on Restart.

Creating User Profile Synchronization Exclusion Filters using the userAccountControl attribute

Planning and implementing Exclusion Filters for SharePoint Server 2010 User Profile Synchronization (UPS) is without doubt one of the most important aspects of any UPS deployment. By making use of Exclusion Filters we can narrow down the objects we sync with. Exclusion Filters reduce the amount of “junk” in the Profile database and can significantly decrease the time taken to perform synchronization runs.

I will be posting more about Exclusion Filters in general soon, but for this post I will concentrate on the most commonly used filter – that of the userAccountControl attribute in Active Directory. This is by far the one I am asked about most, and is commonly misunderstood.

The userAccountControl attribute is used to store the account options for an AD user object. These options include the status of the account (e.g. disabled, or locked out). Each option is a property flag. These flags are cumulative and thus there is only ever one value for userAccountControl.

Therefore it makes sense to create an exclusion filter to avoid synchronizing disabled accounts and so on. This one is easy and finds it’s way into most documentation such as the very good Configure profile synchronization. However it is a bit more tricky when dealing with other property flags and combinations of them.

Let’s start by taking a look at the core capability and exclude disabled accounts.

Once we select the userAccountControl attribute in the Edit Connection Filters page, it will refresh and populate the operators available to us:

Now this is where the fun starts. We could choose the Equals operator to filter on specific values. However, while possible, this is a very bad idea and can lead to unexpected results.

The decimal value of the ADS_UF_ACCOUNTDISABLE property flag is 2. But if we enter 2 in here and save the filter and then run a sync, disabled accounts will still be synced.

Remember that this attribute is cumulative. There is never going to be an account with a value of 2. For an account to be disabled it has to be an account in the first place! A normal disabled user account with no other property flags will be 514:

• Normal User Account (ADS_UF_NORMAL_ACCOUNT) = 512
• Disabled Account (ADS_UF_ACCOUNTDISABLE) = 2

But we shouldn’t use 514 either, because what happens if a disabled account also has the ADS_UF_HOMEDIR_REQUIRED property flag set? Then the value becomes 522. If we want to exclude all disabled accounts, we have a lot of work to do to create filters for each of the potential combinations.

This is where the Bit on equals operator comes into play. This allows us to create filters which filter based upon a bit value.

If we go ahead and create a filter using Bit on equals 2 for the userAccountControl attribute, disabled accounts will always be excluded regardless of other property flags present. It doesn’t matter what the value, the second bit will always be “on”. To illustrate this let’s take the same example:

• Disabled User Account = 514  (In binary that’s 1000000010)
• Disabled User Account with Home Directory Required = 522 (In binary that’s 1000001010)

As you can see in both cases the “second bit is on”.  And this is why we need the filter for disabled accounts to be “Bit on equals = 2”.

The problem here is we need convert the property flag into binary to determine the bit(s) we wish to check, and therefore which value to enter into the filter value text box.

As you may have noticed if you enter a number into the filter value when using the bit on equals operator and save the connection, the number changes when you go back in to view or edit it. Try it with 10 or 36. These values will magically become 16 and 54! This is a known bug and is fixed in the October 2010 CU and later. From the KB:

“You set a numeric value for a filter in a synchronization connection in SharePoint Server 2010. Then you save the filter. In this situation, you notice that the numeric value in the filter has unexpectedly increased when you view the filter again.”

There will never be a bit on equals value to check greater than 25 when using the standard AD property flags (for this attribute).

The next thing to do is to combine filters. Say we want to exclude disabled accounts and also accounts which have the Password Never Expires (ADS_UF_DONT_EXPIRE_PASSWD) flag set (these are commonly service accounts).

We need to add two filters to catch both:

• Disabled Account = 2 (In binary that’s 10)
• Password Never Expires = 65536 (In binary that’s 10000000000000000)

Therefore we need a “Bit on equals 17” for the accounts with the Password Never Expires flag in addition to the “Bit on equals 2” for disabled accounts.

But watch out, there’s a classic gotcha on the Edit Connection Filters page. When we add multiple filters the default operator between them is AND. This means that if we don’t change this, the only accounts that will be filtered in this case will be those that are both disabled and don’t have password expiry. That’s likely to be nowhere near as many as we want.

So we must create them using the OR operator:

If we’ve created them by accident with the AND operator, we have to remove them and recreate them. It gets worse. Take another look at the filter list above. Yup, that’s right, it doesn’t display which operator was applied! There is no way to tell from this UI which one was used. This is easily the number one reason why filters don’t work as expected and why planning and documenting your filters is paramount!

Let’s work through one more example. Say we wish to exclude all accounts which are either disabled, locked out, or for which the password has expired. These are the filters we would need:

• userAccountControl Bit on equals 2 OR
• userAccountControl Bit on equals 5 OR
• userAccountControl Bit on equals 24 OR

So that’s that. This isn’t difficult. But it’s certainly not obvious on first glance, it’s not documented, and it’s not the sort of thing the average SharePoint administrator is comfortable with. The Edit Connection Filters page doesn’t exactly help. Fundamentally this is about converting the property flags into binary to determine the bit(s) we wish to check, and therefore which value to enter into the filter value text box.

Permission levels in SharePoint sites

A permission level (permission level: A set of permissions that can be granted to users or SharePoint groups on an entity such as a site, library, list, folder, item, or document.) enables you to assign a particular set of permissions to users and SharePoint groups so that they can perform specific actions on your site. By creating new permission levels (or editing existing permission levels) with the permissions required to perform common tasks, you can associate an appropriate permission level with the users or SharePoint groups for the securable object on which you want to allow them to perform those actions.

The following permission levels are provided by default: Full Control, Design, Contribute, Read, Limited Access. Anyone assigned to a permission level that includes the Manage Permissions permission can fully customize permission levels (except for the Full Control and Limited Access permission levels) or create new ones. Members of the Site Owners SharePoint group are assigned the Manage Permissions permission, by default.

 Note   Prior to Windows SharePoint Services 3.0, permission levels were called site groups.
Permission levels are managed at the site level. Because of this, you can perform the following tasks on the top-level Web site of a site collection or on any subsite that is using unique permissions. You cannot manage permissions on a subsite that is inheriting permissions from its parent. Instead, you must either manage permissions of the parent, or you must first stop inheriting permissions from the parent site and then create unique permissions on the subsite.
Managing permissions of a parent site affects not only the parent site, but all subsites inheriting from that parent site. Before you manage permissions of a parent site, carefully consider how your changes will affect other sites.

 Create a permission level

On the Site Actions menu , click Site Settings.
 Note   On a site for which the Site Actions menu is customized, point to Site Settings, and then click the settings that you want to view.

1. On the Site Settings page, in the Users and Permissions section, click Advanced permissions.
2. If the Settings menu is not available, select Manage Permissions of Parent from the Actions menu. Otherwise, skip to step 4.

 Note   The Settings menu is not available on the Permissions page if your site is inheriting permissions from its parent site.

3. On the Permissions page, on the Settings menu, click Permission Levels.
4. On the Permission Levels page, click Add a Permission Level.
5. On the Add a Permission Level page, in the Name and Description section, type a name and optionally a description.
6. In the Permissions section, select the permissions you want to associate with this permission level.
7. After you have made your changes, click Submit.

 Copy a permission level

On the Site Actions menu , click Site Settings.
 Note   On a site for which the Site Actions menu is customized, point to Site Settings, and then click the settings that you want to view.

1. On the Site Settings page, in the Users and Permissions section, click Advanced permissions.
2. If the Settings menu is not available, select Manage Permissions of Parent from the Actions menu. Otherwise, skip to step 4.

 Note   The Settings menu is not available on the Permissions page if your site is inheriting permissions from its parent site.

3. On the Settings menu, click Permission Levels.
4. On the Permission Levels page, in the Permission Level column, click the name of the permission level you want to copy.
5. Scroll to the bottom of the Edit Permission Level page, and then click Copy Permission Level.
6. In the Permission Level Name and Description section, type a name and optionally a description for the new permission level.
7. In the Permissions section, select the permissions that you want to associate with this new permission level and clear the permissions that you don't want to associate with this permission level.
8. After you have made your changes, click Submit.

The new permission level appears on the Permission Levels page.

 Edit a permission level

On the Site Actions menu , click Site Settings.
 Note   On a site for which the Site Actions menu is customized, point to Site Settings, and then click the settings that you want to view.

1. On the Site Settings page, in the Users and Permissions section, click Advanced permissions.
2. If the Settings menu is not available, select Manage Permissions of Parent from the Actions menu. Otherwise, skip to step 4.

 Note   The Settings menu is not available on the Permissions page if your site is inheriting permissions from its parent site.

3. On the Settings menu, click Permission Levels.
4. On the Permission Levels page, in the Permission Level column, click the name of the permission level you want to edit.

 Note   You cannot make changes to the Full Control or Limited Access permission levels.

On the Edit Permission Level page, you can make the following changes:

• Change the description of the permission level.
• Select the permissions that you want to associate with this permission level and clear the permissions that you do not want to associate with this permission level.

5. After you have made your changes, click Submit.

 Delete a permission level

On the Site Actions menu , click Site Settings.
 Note   On a site for which the Site Actions menu is customized, point to Site Settings, and then click the settings that you want to view.

1. On the Site Settings page, in the Users and Permissions section, click Advanced permissions.
2. If the Settings menu is not available, select Manage Permissions of Parent from the Actions menu. Otherwise, skip to step 4.

 Note   The Settings menu is not available on the Permissions page if your site is inheriting permissions from its parent site.

3. On the Permissions page, on the Settings menu, click Permission Levels.
4. On the Permission Levels page, select the check boxes for the permission levels you want to delete, and then click Delete Selected Permission Levels.
5. Click OK to confirm.

Inherit permissions from parent site

If your Web site has unique permissions, you can inherit permissions from the parent Web site at any time.
 Important   Inheriting permissions from the parent site permanently discards all custom permissions that you might have created on any securable object for this site. This means that all lists, libraries, folders within those lists and libraries, list items, and documents lose all their unique permission settings.
On the Site Actions menu , click Site Settings.
 Note   On a site for which the Site Actions menu is customized, point to Site Settings, and then click the settings that you want to view.

1. On the Site Settings page, in the Users and Permissions section, click Advanced permissions.

 Note   If the Settings menu is not available on the Permissions page, your site is already inheriting permissions from its parent site.

2. On the Permissions page, on the Settings menu, click Permission Levels.
3. On the Permission Levels page, click Inherit Permission Levels from the Parent Web Site.
4. Click OK to confirm.

Group Permission For Document Library

Senario: We need to write a script for already created a document library called "Audit Logs" for every site collection in our environment. Wanted to ensure that only Site Collection administrators and the individual site Owners group had access to this document library.  
 

Solution:

if ( -not $(Get-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue" )) {Add-PSSnapin Microsoft.SharePoint.PowerShell}

$sites = Get-SPSite | Select RootWeb, URL
   
    foreach ($site in $sites){
      
    $ListName = "Audit Logs"
    $PermissionLevel = "Full Control"
    $web = $site.rootweb
    #$web = Get-SpSite -identity $site.url
    #$web = Get-SPWeb -Identity $site.url       
    $list = $web.Lists | where {$_.Title -match $ListName}
        if ($list -ne $null)
        {
            if ($list.HasUniqueRoleAssignments -eq $False)
            {
                $list.BreakRoleInheritance($True)               
            }
           
            if ($list.HasUniqueRoleAssignments -eq $True)
            {
                ForEach ($SiteGroup in $web.SiteGroups) {                   
               
                    if ($SiteGroup.Name -match "Owners")
                    {
                        #write-host $SiteGroup.Name
                        $GroupName = $SiteGroup.Name
                        $roleAssignment = new-object Microsoft.SharePoint.SPRoleAssignment($SiteGroup)
                        $roleDefinition = $web.RoleDefinitions[$PermissionLevel];
                        $roleAssignment.RoleDefinitionBindings.Add($roleDefinition);
                        $list.RoleAssignments.Add($roleAssignment)
                        $list.Update();
                        Write-Host "Successfully added <$GroupName> to the <$ListName> list in <$site>. " -foregroundcolor Green
                    }               
                    else
                    {
                         Write-Host "No Owners groups exist." -foregroundcolor Red
                    }
                }
                }
            }
        }

Delete site completely

Do you want to delete your site completely?

After deleting your site, just run below two commands in PowerShell.

Get-SPDeletedSite -Identity "your site URL"

After running the first command, it will generate the id like (610857cb-8414-4a89-8bf3-ad3628f6c86)

Note: Use the id to next command

Remove-SPDeletedSite -Identity "Above generated id"

If you got error while running this command, your site already deleted completely.

 

Senario : Sharepoint Site is not loading or slow

Is your home page  in a site  collection that has the Publishing infrastructure feature activated? For example, built off the Collaborative Portal site definition. If so, then your problem is probably just that Page and Fragment caching is disabled. Go to Site Settings for your top level site.

In the Site Collection Administration column you will see an entry to Site Collection Output Cache settings. Go to that page and click the checkbox to enable Output caching. On the same page use the dropdowns to select the anonymous profile for Anonymous Cache and the Intranet profile for the Authenticated Cache. If the checkbox is already checked, make sure you aren't overriding the profiles at the site level by looking at the site output cache settings from the Site Settings page.

If this does not cause a marked improvement on the second page refresh then you have a deeper problem. But Output caching is the most common issue. If its not output caching then we need to talk about the webparts etc on the home  page or any custom code you've added to the home page.

Multiple User in Remote Desktop

When working with Windows Server and connecting to a server via Remote Desktop, one might stumble upon the following error message:

Windows Server: The terminal server has exceeded the maximum number of allowed connections

It turns out that even after clicking “OK”, you will not be able to connect to the server and your session will be terminated. But how to fix this problem without physically going to the server?
Here is a screenshot:


The reason for this error message is quite simple: A terminal server only accepts a finite number of simultaneous connections. Now, when a user connects to a Windows Server, does his thing and then simply closes the Remote Desktop window, the session on the server is not closed but kept open. So the user will remain logged on.
The correct way to terminate a Remote Desktop session is to select “Start”, then “Log off”. This will close the session and allows other users to connect to the server.

Resolving the problem

To connect to the Terminal Server despite the limited connections, what we can do is to connect to the server with the /admin switch. To do this, launch mstsc as follows:

mstsc /v:n.n.n.n /admin

Replace n.n.n.n with the IP of the server and you’re good to go. Once connected to the server, use Task Manager to log off the sessions that are no longer used. The following screenshot shows that there is one connection that has no current connections and can be logged off:

To do this, select the session you wish to disconnect (in my case that is the session with the ID 3) and click “Logoff”. Note that this will effectively log off the session and closes all windows still open in that session!
Once these steps have been completed, log your current session off and you should be able to reconnect to the server without using the /admin switch.

Standard Upload Mode

Standard Upload Mode is enabled if the ASPxUploadControl.UploadMode property is set to UploadControlUploadMode.Standard.

This is a standard FileUpload-based upload mode in which the uploaded file is sent to the server in one request and is cached in its entirety in server memory. This mode works well with small files, but is not suitable for uploading large files (such as 1GB). The ASP.NET worker process has a virtual address space of 2 gigabytes (GB). However, the ASP.NET worker process only uses a little more than 1 GB because of health monitoring and memory fragmentation (see the Cannot Upload Large Files... Microsoft topic for more detail).

Additionally, ASPxUploadControl requires memory for progressing. Therefore, the real maximum size of a file, which can be uploaded using ASPxUploadControl in the standard upload mode with enabled progressing (the ASPxUploadControl.ShowProgressPanel property is set to true), is about 2GB/3 = 633MB.

Allowing large file uploads in this mode also requires increasing the Request length limit (via a Web.Config file's maxRequestLength configuration setting), which is not protected against the rejection of service (DoS) attacks that are caused by users who post large files to the server.

Advanced Upload Mode

To enable the Advanced Upload Mode, set the ASPxUploadControl.UploadMode property to UploadControlUploadMode.Advanced. You can access and customize the settings that relate to the Advanced Mode using the ASPxUploadControl.AdvancedModeSettings property.

In this mode, the uploaded file is sent to the server in small packets (one by one) and is saved into a temporary file within a specific server folder.

The Advanced Mode's implementation is based on modern technologies provided by Microsoft Silverlight. So it is required that your end-users have the Silverlight plug-in (version 3 or later) installed in their browsers. If this plug-in is not installed or is disabled, a specific message is rendered instead of the ASPxUploadControl, providing end-users with a Silverlight download link.

Using the Advanced Mode has the following benefits.

• Uploading Large Files Sending a file in small packets allows end-users to upload large files (up to 2GB) without using a huge amount of web server memory, because only one packet per file is stored in memory at one time. The packet size (which by default is 200 kilobytes) can be customized via the UploadAdvancedModeSettings.PacketSize property. A server folder to which each uploaded file is saved can also be specified via the UploadAdvancedModeSettings.TemporaryFolder property (default path is "~\App_Data\UploadTemp\").
  After the file upload is finished, you can access the uploaded file as a file stream by using the UploadedFile.FileContent property of the related UploadedFile object, while handling the ASPxUploadControl.FilesUploadComplete or ASPxUploadControl.FileUploadComplete server event.
  

  C#

  protected void ASPxUploadControl1_FileUploadComplete(object sender, FileUploadCompleteEventArgs e) { using(Stream stream = e.UploadedFile.FileContent) { stream.Read(...); } }

  C#	protected void ASPxUploadControl1_FileUploadComplete(object sender, FileUploadCompleteEventArgs e) { using(Stream stream = e.UploadedFile.FileContent) { stream.Read(...); } }

  Note
  When using the Advanced Mode, operating the uploaded file's stream within the using statement (Using statement in Visual Basic) is required.

  Refer to the Uploading Large Files topic to learn more on how to customize ASPxUploadControl for large file uploads.
• Preventing DoS Attacks In the Advanced Mode, you are not required to define a large value for the Request length limit (controlled by the maxRequestLength configuration setting within Web.Config), since large files are sent in small chunks. A large value of maxRequestLength makes a website more vulnerable to the rejection of service attacks that may be caused by end-users posting a great number of large files to the server. So using the Advanced Mode allows you to keep the Request length limit reasonably small, preventing potential DoS attacks.
• Client-Side Validation Using the functionality provided by Microsoft Silverlight, ASPxUploadControl is able to validate the file size and extension directly on the client side without sending files to the server. This prevents unnecessary traffic to the web server. Client validation is invoked automatically if the ValidationSettings.MaxFileSize or ValidationSettings.AllowedFileExtensions property is defined. After a file has passed client-side validation, ASPxUploadControl also performs a server-side validation check giving you extra protection.
• Progress Indication in Medium Trust With the Advanced Mode, the functionality of upload progress indication (controlled by the ASPxUploadControl.ShowProgressPanel property) works well in web environments that only allow medium trust. In contrast to the Standard Mode (where the current progress is not updated until file upload is completed), indication of the current progress is updated after each small file packet is uploaded.
• Multi-File Selection in File Open Dialog In an Advanced Mode, ASPxUploadControl supports the multi-file selection capability, allowing end-users to choose several files to upload within a single file open dialog. Refer to the Multi-File Selection topic to learn more.

Comparison of using SQL database mirroring or Log Shipping for SharePoint DR farm

Database Mirroring:

•In database mirroring Real time transaction log shipping to secondary SQL Server. Incase of primary SQL server failure latest information will be available on Secondary SQL Server.

•As Database on Secondary SQL Server would be “Mirror, Synchronized / Restoring” We will not be able to attach the databases to web application on DR farm. Incase of Failover we will need to make the databases active and attach the databases to web applications.

•After failover when we attach the content database to the web application, it will automatically refresh the site map on Configuration database.

•As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.

•When failover happens we need to run SQL script to make the all content databases writeable.
Database Log Shipping:

•In Log shipping transaction log backup, copy and restore happens on scheduled time (Minimum time 1Min). Incase of fail-over from primary SQL Server to Secondary SQL Server we might loose some data if that's not restored on SQL Secondary SQL Server or manually restore the transaction log backup to Secondary SQL Server database.

•As Database on Secondary SQL Server would be “Stand by/ Read-only” It will allow you to attach the databases to web application on DR farm and we can crawl the content using Search Service Application.
•As the databases are attached to the web application we can run a script to refresh the Site Map on Configuration database.

•As we cant attach the databases to the web applications, Search Service Application wont be able to crawl the content. After Fail-over you need to crawl the content.

•When failover happens we need to run SQL script to make the all content databases writeable.
Changes required when you failover from Primary SharePoint 2010 to SharePoint 2010 DR Farm.

If you are using SQL database mirroring:

•On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.

•Run the SQL Query to make the database active. (ALTER DATABASE ContentDatabaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS)

•Attach content databases to the web applications.

•Start a full Crawl process on Search Server.
If you are using SQL database log shipping:

•On the DNS Server make the changes so that all the request can be reached to DR Farm SharePoint 2010 WFEs.

•Restore all the pending transaction logs backup to database.

•Run the SQL Query to make the database active. (RESTORE DATABASE contentdbname WITH RECOVERY)

•Start an Incremental Crawl process on Search Server.
After knowing both the options, now you can choose between database mirroring and Database log shipping for DR farm configuration.

Overview to SQL log Shipping

SQL log shipping allows to backup the transaction logs from primary SQL Server instance in regular interval to one or multiple secondary SQL Server instance. Transaction log backup are restored to all the Secondary SQL Server instances individually.

SQL Log Shipping consist of 3 operations:

•Backup transaction log from the primary server

•Copy the transaction log backup to the secondary server or secondary servers

•Restore the transaction log backup to the secondary server instance

 

Above 3 operation will create 3 jobs on SQL Servers. Backup Job will be only available on Primary SQL Server instance. However, Secondary SQL Server instance contains the Copy job and Restore job. All these job executes in regular interval and you can define the time. SQL agent service has to be on running for log shipping.

•Log Shipping Advantages:

Flexibility to backup, copy and restore the transaction logs.

• Due to scheduled jobs database corruption can be avoided.
• Multiple secondary databases can be configured
• Secondary databases are in read-only and standby mode and can queried if required.
• Log shipping allows multiple standby databases

•Log Shipping Disadvantages:

 

• No option for automatic failover
• Minimum time to synchronize is a min. which can be configured. 
• For failover need to execute SQL Query. not simple as database mirroring.

Note:- Transaction Log Shipping can be configured for the databases having Full Recovery Model. It can not be configured 

SQL Database Mirroring

Database mirroring feature is available in SQL 205 and SQL 2008. Its a solution to provide database high availability and its configured per-database basis. You can only configure the database mirroring for the databases that use the full recovery model. You cannot configure the database mirroring for the System Databases (master, msdb, tempdb & model).

In database mirroring there will be 2 copies of a single database residing on 2 different SQL instance. One SQL server instance act as Primary server and holds the active databases. All the clients or applications connect to this database server. Other SQL Server instance act as Secondary server or mirror server which holds the hot or warm databases.

Once the database mirroring has been configured and databases are synchronized state, failover can be performed without a loss of data. While you configure the SQL database mirroring you can also configure the Witness server. This is going to another SQL instance which would be monitoring the primary SQL server instance. If primary SQL Service fails then witness server will automatically failover the databases from primary SQL server instance to Secondary SQL server instance.

There are 2 operating modes for configuring Database mirroring:

•Asynchronous: This doesn't need the Witness Instance, that means there is no automatic failover. Once the Database server is not available administrator to stop the database mirroring session manually.
•Synchronous: You can configure this with witness server (optional). If you configure with witness server then you get the advantage of automatic failover feature. However, automatic failover requires both the databases to synchronized.

Lets look at the advantages and disadvantages of database mirroring.

•Database Mirroring Advantages:

        ◦Easy setup and maintenance
        ◦Real-time synchronization of transaction log
        ◦Automated failover (in High Availability Mode, Witness Server Instance required)
        ◦Fast & easy Failover
        ◦Using connection strings you can make your application mirroring aware or using SQL alias.

•Database Mirroring limitations: 

         ◦Database mirroring is configured per database not per SQL server Instance.
        ◦Mirror database always in recovery mode and this database can’t be used for any purpose or database queries.
        ◦Database mirroring can only configured for one database to another database. There can’t be more secondary server.
        ◦Database mirroring can’t be configured for once database once than once.

Note:- Database mirroring can be configured for the databases having Full Recovery Model. Database mirroring can not be 

Black screen on Remote Desktop Connection(RDC)

When you try to connect to a remote desktop using mstsc command, after successfully logging in the screen appears black. It seems the remote server has stopped responding.

However the system is processing you request in the background.

Solution
1. Check if too many users connected to the server.If so , request them to free the session.
2. Check if too many processes, services or tasks are running.

To do so, the trick is to press 'Ctrl + Alt + End' key. This will open task manager. Here you can check both, number of users logged on in the Users Tab and running processes in Processes tab.