Flow Tightens Integration with SharePoint Libraries

Flow has released two new triggers and three new actions to support modifying document properties and integrating into workflow process. This is yet another step towards full workflow support between SharePoint and Flow.

Take a look at Merwan Hade's Flow Update for August

Automatically Extract Insights from Videos in OneDrive

With Microsoft Flow and Microsoft's newly released Video Indexer services, extracting insights from videos in libraries, whether it be people, places or any term, can be automated, saving dozens of man-hours over performing manually.

HUGE time saver in the exponentially growing Enterprise Content space of videos.

Check out Adi Regev's article from the Microsoft Flow Mobile Team:  How to gain business insights on videos in your work place

SharePoint Online, OneDrive for Business and O365 Groups Site Deletion Policies

SharePoint Online and ODFB Site Deletion Policies

I was asked to recommend site deletion policies for a client's Office 365 tenant, in addition to methods of house-keeping for ODFB and Office 365 groups. My first thought was SharePoint Site Deletion Policies. as this was the method employed for SharePoint on-site. However, after completing the research, I now believe Office 365 Retention Policies are the best path forward, as these work with not only SharePoint Online, OneDrive for Business and Office 365 Groups, but also Exchange Online.

Read on to learn more:

Retention Policies

Volume and complexity of data is increasing daily – email, documents, instant messages, and more. Effectively managing or governing this information is important because of the need to:

• ·       Comply proactively with industry regulations and internal policies that require content be retained for a minimum period of time – for example, the Sarbanes-Oxley Act might require retention of certain types of content for seven years.
• ·       Reduce risk in the event of litigation or a security breach by permanently deleting old content that is no longer required to keep.
• ·       Help organizations to share knowledge effectively and be more agile by ensuring that users work only with content that’s current and relevant to them.

A retention policy in Office 365 can help achieve all of these goals. Managing content commonly requires two actions:

1.       Retaining content so that it can’t be permanently deleted before the end of the retention period.

2.       Deleting content permanently at the end of the retention period.

A retention policy can:

·       Decide proactively whether to retain content, delete content, or both – retain and then delete the content.

·       Apply a single policy to the entire organization or just specific locations or users.

·       Apply a policy to all content or just content meeting certain conditions, such as content containing specific keywords or specific types of sensitive information.

Retention Policies with Content In-Place

When including a location such as a site or mailbox in a retention policy, the content remains in its original location. People can continue to work with their documents or mail as if nothing’s changed. But if they edit or delete content that’s included in the policy, a copy of the content as it existed when the policy was applied, is retained.

For sites, a copy of the original content is retained in the Preservation Hold library when users edit or delete it; for email and public folders, the copy is retained in the Recoverable Items folder. These secure locations and the retained content are not visible to most people. With a retention policy, people do not even need to know that their content is subject to the policy.

v Skype content is stored in Exchange, where the policy is applied based on message type (email or conversation).

v A retention policy applied to an Office 365 group includes both the group mailbox and site.

OneDrive Accounts and SharePoint Sites

A retention policy is applied at the level of a site. When including a SharePoint site or OneDrive account in a retention policy, a Preservation Hold library is created, if one doesn’t already exist. The Preservation Hold library is only visible to site collection administrators.

When content is changed, or deleted in a site with a retention policy for the first time since the policy was applied the content is copied to the Preservation Hold Library and allows for the change of the original content. New content (added after policy is applied) isn’t copied to the Preservation Hold library the first time it’s edited, only when it’s deleted. To retain all versions of a file, turn on versioning.

After a retention policy is assigned to a OneDrive account or SharePoint site, content can follow one of two paths:

1. If the content is modified or deleted during the retention period, a copy of the original content as it existed when the retention policy was assigned is created in the Preservation Hold library. There, a timer job runs periodically and identifies items whose retention period has expired, and these items are permanently deleted within seven days of the end of the retention period.
2. If the content is not modified or deleted during the retention period, it’s moved to the first-stage Recycle Bin at the end of the retention period. If a user deletes the content from there or empties this Recycle Bin (also known as purging), the document is moved to the second-stage Recycle Bin. A 93-day retention period spans both the first- and second-stage recycle bins. At the end of 93 days, the document is permanently deleted from wherever it resides, in either the first- or second-stage Recycle Bin.

v The Recycle Bin is not indexed and therefore searches do not find content there. This means that an eDiscovery hold can't locate any content in the Recycle Bin to hold it.

Document Versions and Retention Policies

If a document is deleted from a site that’s being retained and document versioning is turned on for the library, all versions of the deleted document are retained.

If document versioning isn’t turned on and an item is subject to several retention policies, the version that’s retained is the one that’s current when each retention policy takes effect. For example, if version 27 of an item is the most recent when the site is retained the first time, and version 51 is the most recent when the site is retained the second time, versions 27 and 51 are retained.

Retaining content for a specific period of time

Retain content indefinitely or for a specific number of days, months, or years. Alternatively, retention policies can also simply delete old content without retaining it.

v The duration for how long content is retained is calculated from the age of the content, not from when the retention policy is applied.

v Choose whether the age is based on when the content was created or (for OneDrive and SharePoint) when it was last modified.

Applying a Retention Policy to an Entire Organization or Specific Locations

Easily apply a retention policy to an entire organization, entire locations, or only to specific locations or users.

Org-wide policy

One of the most powerful features of a retention policy is that by default it applies to locations across Office 365, including:

ü  Exchange email

ü  SharePoint sites

ü  OneDrive accounts

ü  Office 365 groups (applies to content in the group’s mailbox, site, files, OneNote, and Team conversations. Support for content in Planner, Yammer, and CRM is coming soon.)

ü  Exchange public folders

v There is no limit to the number of mailboxes or sites the policy can include.

v For Exchange, any new mailbox created after the policy is applied will automatically inherit the policy.

v Limit of 10 org-wide policies and entire-location policies combined per tenant.

Entire Locations

Include or exclude an entire location, such as Exchange email or OneDrive accounts. Like an org-wide policy, if a policy applies to any combination of entire locations, there is no limit to the number of mailboxes or sites the policy can include.

v Limit of 10 org-wide policies and entire-location policies combined per tenant.

Inclusions or Exclusions

Apply a retention policy to specific users, Office 365 groups, or locations.

However, note that the following limits exist for a retention policy that includes or excludes over 1,000 specific users:

• Retention policies can contain no more than 1,000 mailboxes and 100 sites.
• A Tenant can contain no more than 1,000 such retention policies.

1. Retention wins over deletion. Suppose that one retention policy says to delete Exchange email after three years, but another retention policy says to retain Exchange email for five years and then delete it. Any content that reaches three years old will be deleted and hidden from the users’ view, but still retained in the Recoverable Items folder until the content reaches five years old, when it will be permanently deleted.
2. The longest retention period wins. If content’s subject to multiple policies that retain content, it will be retained until the end of the longest retention period.
3.  Explicit inclusion wins over implicit inclusion. This means:
• 
  
4. The shortest deletion period wins. Similarly, if content’s subject to multiple policies that delete content (with no retention), it will be deleted at the end of the shortest retention period.

• If a label with retention settings is manually assigned by a user to an item, such as an Exchange email or OneDrive document, that label takes precedence over both a policy assigned at the site or mailbox level and a default label assigned by the document library. For example, if the explicit label says to retain for ten years, but the policy assigned to the site says to retain for only five years, the label takes precedence. Note that auto-apply labels are considered implicit, not explicit, because they’re applied automatically by Office 365.
• If a retention policy includes a specific location, such as a specific user’s mailbox or OneDrive for Business account, that policy takes precedence over another retention policy that applies to all users’ mailboxes or OneDrive for Business accounts but doesn’t specifically include that user’s mailbox.
• 
  

SharePoint Online and OneDrive for Business

·        Holds created for eDiscovery in the Security & Compliance Center (eDiscovery hold)

·        Holds created in the eDiscovery Center (eDiscovery hold)

·        Document deletion policies (Deletion only)

·        In place records management (Retention)

·        Site closure and deletion policies (Deletion only)

·        Information management policies (Deletion only)

Note that if any of the eDiscovery holds have been used for the purpose of data governance, instead use a retention policy for proactive compliance. Use a hold created in the Security & Compliance Center only for eDiscovery.

Retention Policies Override Information Management Policies

In SharePoint sites, information management policies may be used to retain content. If a retention policy created in the Security and Compliance Center is applied to a site that already uses content type policies or information management policies for a list or library, those policies are ignored while the retention policy is in effect.

Summary

A single retention policy can easily apply to an entire organization and locations across Office 365, including Exchange Online, SharePoint Online, OneDrive for Business, and Office 365 groups.

There are several other features that have previously been used to retain or delete content in Office 365. These are listed below. These features will continue to work side by side with retention policies and labels created in the Security & Compliance Center. But moving forward, for data governance, best practice is to use a retention policy or labels instead of these features. A retention policy is the only feature that can both retain and delete content across Office 365.

Ü  BEST PRACTICE - To retain or delete content anywhere in Office 365, best practice is to use a retention policy.

Source: Overview of retention policies

Office 365 – You can now manage domain guest access for Groups

Guest Domain Access for O365

An update is being rolled out to let you manage allowed/blocked domains for guest access to Office 365 Groups.

After allowing guest access to Groups, Microsoft now helps securing this access by allowing administrators to define a list of allowed/blocked domains.

This feature is not available (yet?) using the Office 365 administration portal but with PowerShell.

This functionality is using Azure AD policy feature

Important Points

• When using this functionality, you can not define both options. This means any domains not listed as allowed, will then be blocked and vice versa
• Only one policy per tenant
• This is a different list than the one used for SharePoint Online sharing; you will be able to import the existing SPO list but after you will have to manage it separately
• This does not apply to guests already members of an Office 365 Groups; only new guest will have the policy applied

How to use

Install the prerequisites

The PowerShell command to set the domain allow/block list for Office 365 Groups guest access is using the preview modules of Azure Active Directory PowerShell modules.

• You must use Azure AD PowerShell Preview – at least version 2.0.0.98 – you can get Azure AD PowerShell Preview using the following procedure
• Run a PowerShell command prompt using the runadadministrator and check the installed Azure AD PS module installed with the command Get-Module -ListAvailable AzureAD*

• If you get a version different than 2.0.0.98 (or later), you need to uninstall your current version with the command Uninstall-Module AzureAD

• If you have no result or after uninstalling the previous version run the command Install-Module AzureADPreview to install the required preview module; you may be prompted to trust the repository to download the module

Configure the domains list

Once you have the required module installed, you can use the script available https://technet.microsoft.com/library/a86bb46f-0e5b-43a3-b6ef-7394f344a8da#bkmk_script to manage the domains list.

Once you have saved the script you can then use it to add/update/remove/import the domains list

• Create the allow/block domain list Set-GuestAllowBlockDomainPolicy.ps1 -Update –AllowList / –BlockList @("domain1.com", "domain2.com") – this command can be used to overwrite an existing list
• Import the existing list from SharePoint Online Set-GuestAllowBlockDomainPolicy.ps1 –MigrateFromSharepoint: don’t forget after this import you will have to manage it separately
• Add a domain to the existing list Set-GuestAllowBlockDomainPolicy.ps1 -Append -AllowList / –BlockList @("domain3.com")
• Or finally remove the policy with Set-GuestAllowBlockDomainPolicy.ps1 –Remove

Unfortunately there is not (yet?) a way to get the existing list or remove one domain; if you want to remove one domain you need to overwrite the list with the domain(s) you want to remove not included

Reference: Benoit Hamet -  

"Sorry, another account from your organization is already signed in on this computer" - SharePoint Online | Office Apps

OVERVIEW

This issue first popped up in my business' tenant. My office staff were losing their minds and of course not happy with the IT department (okay, me). I have since seen this issue multiple times in my own business as well as my clients.

Inevitably the issue is raised as a SharePoint issue (stupid SharePoint!), something along the lines of:

"I cannot open any SharePoint documents! I get access denied!"

Well..., not so fast. This time, SharePoint is not the issue (yeah, I know, I first, right?) The issue resides with Office 2013(+) apps (whichever version).

In Office 2013(+) apps, you can access Office 365 content in SharePoint Online by providing your Office 365 user ID and password. If you have multiple Office 365 user IDs from different organizations, you can access content from the SharePoint Online deployments of each organization.

However, Office 2013(+) only supports signing in one Office 365 user from each tenant or organization per session.

Office 2013(+) makes a best effort to prevent a user from signing in when another user from the same organization is already signed in. However, there may be cases in which this scenario is not detected, and Office 2013(+) user interface may show that another user is successfully signed in. In this case, the second user cannot access his or her own content. All Office 365 content that he or she tries to open will be performed by using the first user’s credentials.

Be aware that Office 2013(+) respects the permissions of all documents and SharePoint Online libraries. That is, if the first user doesn’t have access to a document that the second user has access to, and the second user (who thinks he or she is signed in) tries to open that document, the document will not open because Office tries to open the document as the first user.

To fix this scenario, the signed-in user can sign out of Office 2013(+), and then restart his or her computer. Doing this makes sure that a clean state is present when the other user tries to sign in again.

PROBLEM

When you try to sign in to an Office 2013(+) app by using your Office 365 user ID and password, you receive the following error message:

"Sorry, another account from your organization is already signed in on this computer."

This behavior is expected. It occurs if you are already signed in to Office 2013(+) by using a different Office 365 user account in the same organization.

WORKAROUND

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs.

Note: I do not recommend this workaround because some account settings may be lost. Additionally, I have fixed this issue for more than a dozen people without touching the registry (step 3), fwiw.

To work around this behavior, remove the existing user account and all connected services from your Office 2013(+) profile, and clear cached credentials that may be on the computer.

Step 1

1. Remove the user account from your Office 2013(+) profile
2. In the upper-right corner of the Office 2013(+) app, click your name, and then click Switch Account.
3. On the Accounts screen, click Sign out.
4. Locate the account that you want to remove, and then click Sign out.

Step 2
Remove connected services from your Office 2013(+) profile

1. Go to File, and then click Account.
2. Under Connected Services, remove all the services for the existing account.

Step 3 (see warning above)

Clear cached credentials on the computer

• Edit the registry to remove cached credentials. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate the following registry subkey: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity\Identities
3. Select the Office account that you want to delete, and then click Delete.
4. In the Identity subkey, locate Profiles, right-click the same Office account that you deleted in step A3 of this procedure, and then click Delete.
5. Exit Registry Editor.

• Remove the cached credentials in Credentials Manager. To do this, follow these steps:

1. Open Control Panel, and then click Credentials Manager.
2. Under Generic Credentials, locate the account that you want to remove, and then click Remove.
3. Log off, and then log on to the computer.

Source:

https://support.microsoft.com/en-us/help/2750229/sorry,-another-account-from-your-organization-is-already-signed-in-on

SharePoint Online's User Profile Synchronization Process (One-way only!)

SharePoint Online's AD attribute sync process has changed quite a bit from on premise or SP 2016 Server version (understandable). However, the depth of that change was surprising to me and my collegues. While researching a solution for users at my current client Toyota of North America, to upload a photo of themselves and have that photo sync to O365 and on-premise Exchange/Skype, as well as Workday, I dug deep and have listed the changes that were pertinent to my task. Take a look and let me know your thoughts.

AD DirSync Import syncs a subset of the Azure Active Directory attributes that are synced by Azure AD Connect. The profile properties that are synced by AD Import aren't configurable.

The following are my observations after research:

• Active Directory information only goes in one direction f rom the on-premises Active Directory server to SharePoint Online
• Data flow:  AD on Premise -> Azure Active Directory -> SharePoint Online directory store -> SharePoint Online User Profile Service -> SharePoint Online Site Collection (one-way)
• User Profile Synch Service’s timer job’s run frequency cannot be changed, which occurs during regularly scheduled one-way synchronization—which should occur at least every 24 hours.
• AD Import syncs a subset of the Azure Active Directory attributes that are synced by Azure AD Connect. The profile properties that are synced by AD Import aren't configurable.
• AD Import syncs the following 24 Azure Active Directory attributes to the User Profile Application: 

      

     

Azure Active Directory attribute	SPO User Profile property	Notes
UserPrincipalName	DisplayName: User Name Name: UserName	The value in this property is used to create the path of a user’s OneDrive for Business site collection. For example: gherrera@contoso.com and /gherrera_contoso_com/ This property is replicated to the site collection by WSS Sync.
UserPrincipalName	DisplayName: Account name Name: AccountName	This property stores the claims-encoded User Principal Name for the user. For example: i:0#.f|membership|gherrera@contoso.com This property is used to look up the user profile.
UserPrincipalName	DisplayName: Claim User Identifier Name: SPS-ClaimID	This property stores the user’s claims identifier. The identifier is the User Principal Name. For example: gherrera@contoso.com
UserPrincipalName	DisplayName: User Principal Name Name: SPS-UserPrincipalName	This property stores the User Principal Name of the user. For example: gherrera@contoso.com
GivenName	DisplayName: First name Name: FirstName	This property is replicated to the site collection by WSS Sync. For example: Gabriela
sn	DisplayName: Last name Name: LastName	This property is replicated to the site collection by WSS Sync. For example: Herrara
Manager	DisplayName: Manager Name: Manager	The manager property is used to determine colleagues and will be used in the user profile and OneDrive for Business deletion process.  For more information see: 3042522 How user profiles are deleted in SharePoint Online and OneDrive for Business.
DisplayName	DisplayName: Name Name: PreferredName	This property is replicated to the site collection by WSS Sync. For example: Gabriela Herrara
telephoneNumber	DisplayName: Work phone Name: WorkPhone	This property is replicated to the site collection by WSS Sync. For example: (123) 456-7890
proxyAddresses	DisplayName: Work email Name: WorkEmail	Processed in this order when it's added to the profile:  WorkEmail if the value in proxy address is prefixed with SMTP: (Must be in CAPS) WorkEmail if the value in proxy address is prefixed with smtp: (Must be lowercase) This property is replicated to the site collection by WSS Sync. For example: gherrera@contoso.com
ProxyAddresses	DisplayName: SIP Address Name: SPS-SIPAddress	SPS-SIPAddress if the value in proxy address is prefixed with sip:. This property is replicated to the site collection by WSS Sync.
PhysicalDeliveryOfficeName	DisplayName: Office Name: Office	This property is replicated to the site collection by WSS Sync.
Title	DisplayName: Title Name: Title	This property is replicated to the site collection by WSS Sync
Title	DisplayName: Job Title Name: SPS-JobTitle	SPS-JobTitle contains the same value as Title. SPS-JobTitle is connected to a Term Set. This property isn't replicated to the site collection.
Department	DisplayName: Department Name: Department	This property is replicated to the site collection by WSS Sync.
Department	DisplayName: Department Name: SPS-Department	SPS-Department contains the same value as Department. SPS-Department is connected to a Term Set. This property isn't replicated to the site collections.
WWWHomePage	DisplayName: Public site redirect Name: PublicSiteRedirect
PreferredLanguage	DisplayName: Language Preferences Name: SPS-MUILanguages	SPS-MUILangauges is used by SPO to determine which language a site is displayed in for the user when MUI is enabled.
msExchHideFromAddressList	DisplayName: SPS-HideFromAddressLists Name: SPS-HideFromAddressLists
msExchRecipientTypeDetails	DisplayName: SPS-RecipientTypeDetails Name: SPS-RecipientTypeDetails
ObjectGuid	DisplayName: Active Directory Id Name: ADGuid	Internal
DistinguishedName	DisplayName: Distinguished Name Name: SPS-DistinguishedName	Internal
ObjectId	DisplayName: msonline-ObjectId Name: msOnline-ObjectId	Internal
UserType	DisplayName: SPS-UserType Name: SPS-UserType	Internal

There are four processes in the user synchronization pipeline in Office 365:

Sync process	Description
Azure AD Connect	Azure AD Connect syncs data from your on-premises Active Directory to Azure Active Directory. For more information, see: Integrating your on-premises identities with Azure Active Directory.
AAD to SPO Sync	Azure Active Directory syncs data from Azure Active Directory to the SPO Directory Store.
AD Import	Active Directory Import syncs data from the SPO Directory Store to the User Profile Application.
WSS Sync	WSS Sync syncs data from the User Profile Application to the SharePoint Online site collection.

• Source: Information about user profile synchronization in SharePoint Online
• Source:  Manage SharePoint Online user profiles from the SharePoint admin center (see extract below)

Default user profile properties are fed into SharePoint Online from the Office 365 directory service. But a SharePoint Online admin can enhance the SharePoint capabilities by adding user profile properties, defining user policies, and creating audiences.
 SharePoint Online receives profile information from the Office 365 directory service during regularly scheduled one-way synchronization—which should occur at least every 24 hours.
 When your organization signs up and deploys Office 365, user accounts will either be:
·        Manually created and added to the Office 365 directory service, or
·        Synched with an on-premises Active Directory.
 If your organization manually created user accounts in the Office 365 directory service, then users will receive Microsoft Azure Active Directory credentials for signing into Office 365. These credentials are separate from other desktop or corporate credentials. You’ll use the Office 365 admin center to make changes to these user accounts.
 Your organization may choose to use the Office 365 Directory Sync (DirSync) tool to populate user information from an on-premises Active Directory. DirSync supports federated single sign-on. For information about setting up DirSync, see Set up directory synchronization for Office 365.

 The Directory Synchronization Tool (DirSync) allows on-premises Active Directory user profiles to be synchronized with the Office 365 directory service, which is then synched with SharePoint Online user profiles. Active Directory information only goes in one direction—from the on-premises Active Directory server to SharePoint Online. This ensures that user information in SharePoint Online reflects the most current and accurate state of your user data in Active Directory.
 Note:  Automatic profile synchronization with the Office 365 directory service occurs at regular predetermined intervals. Changes may take up to 24 hours before they appear in a user’s profile. Note that with Office 365 for Education, user profiles are not created or synced until a user visits a SharePoint site.
 By default, SharePoint Online user profiles are populated by the Office 365 directory service. Basic profile properties, such as a user’s first and last name, phone number, and job title, are also synchronized. If there are additional properties that you’d like to add to user profiles to enhance search and collaboration features within SharePoint, then the SharePoint Online admin can create those user profile properties. See Add and edit user profile properties for more info.
 Note:  Creating a new user profile property, by using SharePoint Online admin center, will not create that property in the Office 365 directory—this user profile data will be unique to SharePoint Online.
 As shown in the following illustration, a user’s About me page can be composed of properties that are imported from the Office 365 directory service and from custom SharePoint Online profile properties. For example, the directory service will supply default user profile information, such as users’ account names, work telephone numbers, job titles, and work email addresses. Users will not be allowed to edit this information.

SharePoint Content Database PowerShell Scripts

There are a number of PowerShell database cmdlets provided by SharePoint; in this tip I will cover the ones that deal with content databases.  The following is the outline for this tip:

• PowerShell 101 - getting setup to use PowerShell to manage content databases
• Get-SPContentDatabase - get information about content database(s)
• New-SPContentDatabase - create a new content database in a web application
• Dismount-SPContentDatabase - detach a content database from a web application
• Mount-SPContentDatabase - attach a content database to a web application
• Remove-SPContentDatabase - detach a content database from a web application and drop the database from the SQL Server instance; be careful with this one!
• Set-SPContentDatabase - set properties of a content database
• Test-SPContentDatabase - test a content database against a web application to see if all of the customizations in the content database are in the web application

If you choose to use SharePoint Central Administration to manage content databases, you'll use the Manage content databases option in the screenshot below.  I will cover using Central Administration to manage content databases in a future tip.

PowerShell 101

There are quite a few tips on using PowerShell to perform various SQL Server tasks; take a look at the PowerShell tips category onMSSQLTips.com for some great content.   For managing SharePoint content databases, you have two options available in Windows Server 2008:

• SharePoint 2010 Management Shell
• Windows PowerShell ISE

The SharePoint 2010 Management Shell is installed automatically by SharePoint; you can find it in the Microsoft SharePoint 2010 Products program group.  The user interface is pretty much like the Command Prompt; it is simple and effective.  The Windows PowerShell ISE is what I prefer; it is a GUI tool that's a little more polished than the SharePoint 2010 Management Shell.  A good SQL Server analogy would be SQLCMD versus SQL Server Management Studio.

Windows PowerShell ISE is not installed by default on your Windows 2008 server; follow these steps to install it:

• Go to Server Manager, Add Features
• Check Windows PowerShell Integrated Scripting Environment (ISE)

After installing Windows PowerShell ISE, you can launch it from the Accessories / Windows PowerShell program group.  There is one additional step that you need to perform in order to use it with SharePoint; you need to load the Microsoft.SharePoint.PowerShell snap-in.  There are two ways to do this:

• Run the PowerShell command Add-PSSnapin Microsoft.SharePoint.PowerShell (every time you open PowerShell ISE)
• Add the snap-in in the profile file; e.g. C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 (one time)

The following is an example of the code you can put in the profile to add the snap-in:

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

There is one more thing you need and that is proper permission to use PowerShell to update a content database and the farm configuration database; you need to be a member of the SharePoint_Shell_Access database role in the respective databases.  You will need a SharePoint farm admin to add you to this role using the Add-SPShellAdmin cmdlet.

Add a user to the SharePoint_Shell_Access role in the farm configuration database only:

Add-SPShellAdmin-UserName domain\username

Add a user to the SharePoint_Shell_Access role in the farm configuration database and content database specified:

Add-SPShellAdmin -UserName DOMAIN\USERNAME -Database DATABASENAME

Add a user to the SharePoint_Shell_Access role in the farm configuration database and every content database:

Get-SPContentDatabase | Add-SPShellAdmin -UserName DOMAIN\USERNAME

Introduction

Here are a couple of points before we get in to the details:

• If you are new to SharePoint 2010, take a look at our earlier tip Introduction to SharePoint 2010 for DBAs.  In the sections that follow the concepts presented in the earlier tip are fundamental to your understanding.
• A content database can either be attached to a web application or detached; where a cmdlet works with a content database that is detached you will see the -Name parameter; when a cmdlet works with a content database that is attached to a web application you will see the Identity parameter; the Identity parameter can be the database name, its Id (GUID or UNIQUEIDENTIFIER as returned by Get-SPContentDatabase), or a SPContentDatabase object in the PowerShell pipeline.
• Along the same lines you don't specify the DatabaseServer parameter when a content database is attached to a web application; SharePoint knows where it is.
• In the sample code when I use contentdb I mean the database name
• I'm running the PowerShell cmdlets on a Windows 2008 server that is connected to a SharePoint farm; I'm not going in to running the cmdlets remotely.

Get-SPContentDatabase

Get-SPContentDatabase returns information about one or more content databases in the SharePoint farm.  The server where you run the command is connected to a particular SharePoint farm so the available databases include only those in the farm. 

To show information about all databases in the farm, run the Get-SPContentDatabase cmdlet without any parameters.  The output is (only one database shown):

Id : 2fb2c72c-e098-4405-9d39-fefd3686fb67
Name : WSS_Content
WebApplication : SPWebApplication Name=SharePoint - 80
Server : DEV-FARM
CurrentSiteCount : 2

Server is the name of the database server; the current site count is the number of site collections in the content database.  To get information about a particular database you can add the -Identity contentdb parameter.

New-SPContentDatabase

To create a new content database run the New-SPContentDatabase cmdlet.  I would contend that this is the most important of the database cmdlets as it allows you to create content databases that you can then use for specific site collections.  A typical command to create a new content database would be:

New-SPContentDatabase -Name contentdb -DatabaseServer dbserver -WebApplication webappname `
  -MaxSiteCount 1 -WarningSiteCount 0

The funny character at the end of the first line above is the one to the left of the number 1 on your keyboard; it is the PowerShell line continuation character (a very poor choice in my opinion).  Note that the content database is associated with or owned by a web application.  You will likely need to get the web application name from your SharePoint administrator.  An example web application name would be http://intranet.yourdomainname.com. 

You can (and probably should) specify the MaxSiteCount parameter to limit the number of site collections that can be stored in this content database; the default value is 15,000.  I prefer to set the MaxSiteCount to 1 so that someone using SharePoint Central Administration to create a new site collection doesn't inadvertently put in in this content database.  The MaxSiteCount can be changed with the Set-SPContentDatabase cmdlet (described later) or in Central Administration.

Creating a content database is the first step in proactively managing your content databases.  The next step is to specify which site collection(s) are to be stored in the content database.  Your SharePoint administrator should use the New-SPSite cmdlet along with the ContentDatabase parameter when creating a new site collection in order to specify the content database for the site collection.  If you are using Central Administration to create site collections you cannot directly specify the content database for the site collection; you can make sure that only one content database is available by setting the MaxSiteCount or Database Status (described later).

Dismount-SPContentDatabase

Dismount-SPContentDatabase detaches a content database from the web application.  You would do this if you wanted to move the content database to a different web application and/or a different database server.  The operation updates the farm configuration database but otherwise leaves the content database intact in the SQL Server instance.   

A typical command to detach a database would be:

Dismount-SPContentDatabase -Identity contentdb

Mount-SPContentDatabase

Mount-SPContentDatabase is the inverse of Dismount-SPContentDatabase.  In this case you are attaching a content database to a web application.  This would be the case if you ran Dismount-SPContentDatabase and are now ready to attach the content database to a different web application or you moved a detached content database from another database server. 

A typical command to attach a content database would be:

Mount-SPContentDatabase -Name contentdb -DatabaseServer dbserver -WebApplication webappname

Mount-SPContentDatabase can also be used when you upgrade a SharePoint 2007 database to SharePoint 2010; this is referred to on TechNet as the database attach upgrade method  The database will be upgraded to the SharePoint 2010 schema and attached to the web application.  You will get a list of any errors or warnings generated by the upgrade.  Typical errors have to do with customizations referenced in the content database that are not in the web application.  I will not cover those issues here as the DBA isn't usually (hopefully) the person who needs to resolve them.

Remove-SPContentDatabase

Remove-SPContentDatabase detaches a content database from the web application and drops it from the SQL Server instance.  As a general rule I don't use this one.  Even if I do want to drop the database I use Dismount-SPContentDatabase then go to SQL Server Management Studio and drop the database. 

A typical command to detach a content database and drop it would be:

Remove-SPContentDatabase -Identity contentdb

Set-SPContentDatabase

Set-SPContentDatabase is used to set the properties of the content database.  Typical properties to set are:

• MaxSiteCount - the maximum number of site collections that can be stored in the content database
• WarningSiteCount - the number of site collections when a warning notification is sent
• Status - Disabled (no site collections can be added) or OnLine (site collections can be added as long as the MaxSiteCount hasn't been reached)

A typical command to disable new site collections from being added to the content database would be:

Set-SPContentDatabase -Identity contentdb -Status Disabled

A typical command to enable new site collections to be added to the content database would be:

Set-SPContentDatabase -Identity contentdb -Status OnLine

As an aside there is a little bit on inconsistency with the content database Status in Central Administration versus the Set-SPContentDatabase cmdlet.  If you select the Manage content databases option from Central administration, you will see a list of content databases with a Database Status column that has the values Started or Stopped.  When you select a database to view or modify its properties, you will see a Database Status dropdown with the options Ready and Offline.

Test-SPContentDatabase

Test-SPContentDatabase will check a content database against a web application to determine whether all of the customizations referenced in the content database are available in the web application.  This cmdlet can check a content database that is attached to a web application or one that is detached.  In either case the output of the command is a list of errors and warnings which hopefully will be resolved by someone other than the DBA.  This is the same list that Mount-SPContentDatabase generates when you are attaching a SharePoint 2007 content database to SharePoint 2010.

A typical command to test a content database that is attached to a web application would be:

Test-SPContentDatabase -Identity contentdb

A typical command to test a content database that is not attached to a web application would be:

Test-SPContentDatabase -Name contentdb -WebApplication webappname