SharePoint: Permission Error When Attaching Existing Content DB

I recently backed up a content database from production and restored it onto a staging server. When attempting to add it to a new web application, I received an error related to SQL Server:

The SELECT permission was denied on the object 'sysobjects', database 'mssqlsystemresource', schema 'sys'.
The SELECT permission was denied on the object 'sysobjects', database 'mssqlsystemresource', schema 'sys'.

The message box had the same message twice. The problem was that the SharePoint Admin account had the deny permissions checked. The easy fix was to open SQL Server Management Studio and modify the roles of the admin account on the restored content database:

 

 

Make sure that db_denydatareader and db_denydatawriter are unchecked. Once I unchecked those roles and clicked OK, I was able to attach the content database to my new web app.

 



 

SharePoint 2013: Allowing Users to Sort Search Results

In previous versions of SharePoint, the out-of-the-box search results provided links to show results by relevance or modified date. Now, with SharePoint 2013, the results may be sorted by any managed property but there are a few preset values. However, by default, the sort option is not enabled. So to allow your users to sort search results, follow these simple steps:

1) Edit one of the results pages in your search center site and Edit the Search Results web part:

 

2) In the web part tool pane, scroll down and expand the Settings section. Click the Show sort dropdown checkbox:

 

The sort options are controlled by the JSON in the Available sort orders text box. You may modify this to add or remove sort options. Feel free to choose from any of the 600+ managed properties available out-of-the-box.

3) Click OK in the toolpane and check-in the changes of the page.

4) Perform a search. A drop-down appears above the results:

 

Windows Azure: Creating a Virtual Machine in a Virtual Network

Here is a comic-book style post explaining how to create a virtual network and virtual machine within Windows Azure. I performed these tasks to create an ADFS 2.0 server in the cloud for Office 365. I blanked out several items for security purposes. Enjoy!

 

 

 

Windows Azure: SQL Server Issues with VC++ Manifests

Not only did I run into this issue once, but I ran into again after fixing it the first time. Same issue, same resolution steps, but slightly different causes. I believe the root cause is the Windows Updates to the VC++ redistributable files causing manifest files to be blank.

Initial Problem
I installed SQL Server on Windows Azure for a SharePoint Development environment. Everything was fine. I ran Windows Updates and rebooted. I think once the server was back up, I focused on installing SharePoint on a different virtual machine. Anyway, when I did finally come back to the SQL Server VM, I could not launch SQL Management Studio. I received an error:

The application has failed to start because its side-by-side configuration is incorrect.

 

 

Originally I thought I did something wrong as I was running installations and doing too many things at once. So the first time I just rebuild the server. After I did that and ran the Windows Updates and received the same error (The application has failed to start because its side-by-side configuration is incorrect.), I figured it wasn't me and maybe something else.

 

I found the solution to my intial problem here. The resolution worked like a charm. Essentially, the manifest file for the ATL80.DLL was blank. The steps from that forum post are here:

 

takeown /f C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.4053_none_8a1a02152edb659b.manifest

icacls C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.4053_none_8a1a02152edb659b.manifest /grant Administrators:F

notepad C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.4053_none_8a1a02152edb659b.manifest

When the empty file (actually I saw some blank space in there) opens in notepad, you just need to paste the following in there are save:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><!-- Copyright © 1981-2001 Microsoft Corporation --><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">    <noInheritable/>    <assemblyIdentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.4053" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"/>    <file name="ATL80.dll" hash="99840dcc34e78af239d80841eba316c184e407cd" hashalg="SHA1"/></assembly>

Worked great! I thought I was done!

Continued Problems
Today when I fired up my SharePoint site, it could not connect to the configuration database. When I remoted into my SQL Server VM and attempted to run SQL Server Management Studio, I received the same error: The application has failed to start because its side-by-side configuration is incorrect.

OK. I thought I knew how to fix it. But when I ran the commands above from the original forum post, the manifest file still had the contents in there. So it must be something else. Ahhh.

So I remembered I found a way to determine the errors from this post here.

You run the trace, perform the action that doesn't work, and then stop the trace and convert it to readable format. At the bottom of the log, you'll see the error similiar to this:

INFO: Parsing Manifest File C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_8a1dd9552ed7f8d8.manifest.
 INFO: Manifest Definition Identity is (null).
 ERROR: Line 0: XML Syntax error.
ERROR: Activation Context generation failed.
At one point before I did the trace, I just decided that I only needed SQL Server running and noticed the service was not active. When attempting to even start the service, I received a similiar error:

 

Windows could not start SQL Server (MSSQLSERVER) service on Local Computer.

Error 14001: The application has failed to start because its side-by-side configuration is incorrect.

 

 

I used the trace method and actually had to fix two additional manifest files - the x86 and the amd64 flavors of the 8.0.50727.6195 version of ATL80.dll. So to save people trouble, I included the commands and the content to paste back into the files.

 

 

x86 8.0.50727.6195



takeown /f C:\Windows\WinSxS\manifests\x86_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d1cb102c435421de.manifest
icacls C:\Windows\WinSxS\manifests\x86_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d1cb102c435421de.manifest /grant Administrators:F
notepad C:\Windows\WinSxS\manifests\x86_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d1cb102c435421de.manifest


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright © 1981-2001 Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable/>
    <assemblyIdentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
    <file name="ATL80.dll" hash="b5037a793da006b9cbf7497aad5886358a578095" hashalg="SHA1"/>
</assembly>
amd64 8.0.50727.6195
takeown /f C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_8a1dd9552ed7f8d8.manifest
icacls C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_8a1dd9552ed7f8d8.manifest /grant Administrators:F
notepad C:\Windows\WinSxS\manifests\amd64_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.6195_none_8a1dd9552ed7f8d8.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><!-- Copyright © 1981-2001 Microsoft Corporation --><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">    <noInheritable/>    <assemblyIdentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.6195" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"/>    <file name="ATL80.dll" hash="c7e340d6abcbb023cbfd848a292f6583f4227105" hashalg="SHA1"/></assembly>

Hope this helps!!!
 

PowerShell: Running Unsigned Scripts

Although you may fire up PowerShell and enter commands at will, if you attempt to run a script file, initially you may receive an error:

File cannot be loaded because the execution of scripts is disabled on this system.

By default things are locked down. Scripts must be signed in order to be executed. This is for trust and security purposes. However, for development and staging/testing environments, you probably just want it to run.

Simple fix!

All you need to do is modify the execution policy by issuing one of the following cmdlets:

Set-ExecutionPolicy remotesigned
   -- or --
Set-ExecutionPolicy unrestricted

The remote signed protects against downloaded scripts and insures that they must be signed. Unrestricted allows any script to be run so that's what I do in development and staging/testing:

The remote signed is probably good for production depending on your IT policies.