Inconvenient Settings Loss With Dismount-SPContentDatabase
Are you someone that likes to go through your web applications and dismount your databases prior to patching? Or maybe you’re just moving a content database from one web application to another. Or maybe, just maybe, you want to dismount a content database for the fun of it!
Well, if that’s you, you might have noticed (or maybe not), that when the content database is remounted, a few properties get reset to their default values such as MaximumSiteCount and WarningSiteCount (2,000 and 5,000 respectively). This can be pretty inconvenient (to say the least!) if you’ve modified these settings in any way and even more inconvenient if you didn’t document them before running Dismount-SPContentDatabase.
Once again, it’s our friend PowerShell to the rescue. The following functions allow you to dismount all of the content databases in a given web application (Dismount-SPContentDatabases) while retaining the pertinent settings in CSV file. The function helpfully titled Mount-SPContentDatabases will remount the content databases (using Mount-SPContentDatabase) to the supplied web application using the previous settings (including the original DatabaseServer), thus saving you at least 5 minutes to enjoy an additional cup of coffee.
Imagine you have a web application with the name ContosoIntranet.
SharePoint 2013 Additional Prerequisites Unavailable for Download
As you’re all aware, SharePoint 2013 has some additional prerequisites that are required for a proper installation that aren’t included in the Prerequisite Installer. Todd Klindt just had a great post on this (so go there for the extra details), but he forgot to mention that 2 of the required hotfixes don’t currently have publicly available request forms. Todd was also nice enough to include some download links, so I’m posting them here as well for posterity.
Office 365 Sign-In Changes
Coming in March 2013, following the release of the next version of Office 365, users will be presented with a streamlined sign-in experience. The sign-in page will a feature responsive design and was designed to “provide the best possible performance and experience on computing devices”.
If you’d like to opt-in earlier and test drive the new experience, click here.
Post opt-in, here’s what you’ll experience on the desktop.
Shredded Bits. It’s What’s For Breakfast
Presenting SharePoint Worst Practices and Blunders
Easily Hide Columns on a SharePoint Form with PowerShell
Marc Anderson recently had a post on his site titled Easily Hide Columns on a SharePoint Form with jQuery. As with all things SharePoint, there are a number of ways to approach a solution, so I thought I’d offer it up in PowerShell (or Po$h as it were).
So, if you’ve ever asked yourself
I want to hide columns in my list forms but I don’t know any jQuery! What is an IT Pro to do?
I’ve got an answer for you!
I have a custom list at http://intranet.contoso.com/Lists/CustomList with a single column added called HideOnNewShowOnEdit (creative right?). Through the use of the ShowInNewForm property on the SPField object, we’ll mask the field and prevent it from being shown in any NewForm.
There are a few more properties which will aid you in your field hiding journey. Take a look at:
My Sites and The SPDataAccess SQL Role
You’ve been busy spinning up your RTM SharePoint 2013 farms haven’t you? And of course, you’ve been deploying under the least-privileged security model like any good IT Pro. After you have everything configured, you open the event viewer and what to your wondering eyes should appear? An error of course!
The error and why
So, why is my content Application Pool attempting to access My Sites? Well, if we read Account permissions and security settings in SharePoint 2013 (go ahead, I’ll still be here when you finish) under the SharePoint service application accounts section (specifically My Sites application pool account) there’s a little follow-section titled Other application pool accounts. Let’s take a look at the permissions our “Other” pool accounts should be granted automatically:
|Configuration Item||Works as advertised|
|This account is assigned to the SP_DATA_ACCESS role for the content databases.||No*|
|This account is assigned to the SP_DATA_ACCESS role for search database that is associated with the web application||No**|
|This account must have read and write access to the associated service application database.||Yes|
|This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the farm configuration database.||Yes|
|This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the SharePoint_Admin content database.||Yes|
* The account is not automatically added to the My Sites content database(s). If it was, we wouldn’t be here.
** The search databases don’t have the SPDataAccess role.
Fixing the error
To alleviate the error (and make your servers happy again!), we’ll be heading off to SQL and executing a quick query on each content databases associated with your My Sites web application: