If you need to force a tape to be free when you’re using System Center Data Protection Manager you can use the PowerShell script ForceFree-Tape.ps1. The syntax of this command had me stuck for a while, so here’s a post to explain it.
- Run the DPM Management Shell as an administrator.
- Enter ForceFree-Tape.ps1.
- Enter the DPM server name.
- Enter the library name. There’s no need to add speech marks for spaces in the name.
- Here’s the bit that got me stuck. Enter the location of the tape to be force free as slot-x, where x is the slot number of the tape you wish to erase. Press enter and repeat the process for multiple slots.
- When you’ve entered the location of the slots you wish to force free press Enter again.
Disabling User Account Control (UAC) in Windows Server 2012 & Windows Server 2012 R2 should be simple; open Control Panel -> User Accounts, click on Change User Account Control settings, select Never notify.
The reality is somewhat different. Following the installation of some software, I needed to run a batch file to delete files from multiple drives on a server. Right-clicking the batch file and choosing “Run as Administrator” didn’t delete the files. Double clicking the batch file had the same problem. Disabling UAC through Control Panel didn’t help things.
The answer was to set the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System EnableLUA registry key to 0x00000000 as per the following MSDN article here. Following a reboot, UAC was completely disabled and the batch file worked correctly.
I’ve also found the registry change was required to enable the Dell 220.127.116.11 patch for Open Manage Server Administrator to install. Without the registry change I was unable to get the patch to install correctly. This included running the patch with UAC enabled and choosing the option to continue when the UAC prompt popped up, and running with UAC disabled via Control Panel.
Using the Restricted Read permission in SharePoint 2013 it’s possible to prevent access to historical versions of documents, but it doesn’t work how I expected it to.
To enable the Restricted Read permission within a document library choose Library Settings from the ribbon. Next click Permissions for this document library. Tick the box next to the group for which you wish to enable Restricted Read and click Edit User Permissions from the ribbon.
On the screen that loads untick Read and tick Restricted Read. Click OK to close.
This is where things don’t work as I expected. I expected that when accessing the document library, the Version History option would be removed from the document properties menu, or the version history would only show the latest version. However, when a user with Restricted Read attempts to open the document library from Site Contents they receive the error “Sorry, this site hasn’t been shared with you.”
Restricted Read is described as providing view access to documents. It turns out that this is possible, but only via a direct link to documents in the library e.g. a URL on a page or search.
Following the installation of SharePoint 2010 SP2 I noticed a large number of event log errors for the Publishing Cache on web front end servers. The error was “An error occurred in the blob cache. The exception message was “The system cannot fine the file specified. (Exception from HRESULT: 0x80070002)”.
Looking deeper into the error using the ULSViewer I could see that the error was being caused by language pack files that could not be found. The files could not be found because following the installation of the language pack the Publishing Infrastructure feature had not been reactivated. The TechNet notes here state “After you install a new language pack, you must deactivate and then reactivate any language-specific features before you use the new language pack.”
In order to resolve the error I went into Site Settings -> Site collection features. I deactivated the SharePoint Server Publishing Infrastructure, then activated the feature. You need to do this out of hours and it does affect your SharePoint site while the feature is deactivated.
In this post I’ll describe the process of federating SharePoint 2013 search queries to Bing.
Open Central Administration and navigate to the Search Service Application. If necessary, configure a proxy server and tick the box to use the proxy settings for federated sources.
Next, click on Result Sources under Queries and Results.
Enter a name for the result source and choose OpenSearch as the protocol.
In the source URL box enter:
Leave the Credentials Information as Anonymous, click Save.
Edit the search page you want to use the display the Bing results. Choose Edit Web Part for the Search Results web part.
Click on Change query.
Change the query source to the Results Source you created earlier and click Ok.
Click OK to save the web part properties and save/check-in/publish your page.
Run a search to see the Bing results.
Having configured SharePoint 2010 Search I had a problem whereby some users received zero results when searching SharePoint content.
In this configuration SharePoint was in one forest (A) and the users who got zero results were in another forest (B). Users in the A forest were able to search and get results. In order to resolve the issue I had to convert the SharePoint Search Service Application to store the SharePoint ACLs in Claims format.
To convert the SharePoint Search Service Application open the SharePoint Management Shell and run Get-SPServiceApplication. Copy the ID of the Search Service Application.
Now run the code below replacing %SearchServiceID% with your Search Service Application ID.
$SearchApp = Get-SPServiceApplication %SearchServiceID%
Run a full crawl and users in the other forest will get search results.
These are notes from my first upgrade of SharePoint 2010 to SharePoint 2013. The purpose of the upgrade is to carry out an initial test upgrade to find any issues etc. I’m not replicating the environment in terms of server roles etc. everything is installed on one server with local SQL. I followed the steps outlined here: http://technet.microsoft.com/en-us/library/cc303436.aspx
This is part 2, part 1 can be found here, part 2 here, part 3 here, part 4 here and part 5 here.
Copy databases to the new farm for upgrade to SharePoint 2013
As this is a test upgrade, don’t set the databases to read-only.
Backup all the SharePoint 2010 content databases and the databases for any service applications you’re going to upgrade. See part 1 for upgradeable service applications.
Copy the SharePoint 2010 database backups to the SharePoint 2013 SQL server.
Restore the SharePoint 2010 database backups on the SharePoint 2013 SQL server.
If upgrading SQL server versions, change the database compatibility level to match the new SQL server version.