SharePoint 2013 Recycle Bin Tricks

To get to the recycle bin:

Open any site

Click on “Settings” icon in the top right side of the site

Select “Site Contents”

Select Recycle Bin on the right

It will take you to this page.


This is the 1st Stage “Recycle Bin”

When you delete from the 1st stage recycle bin, items are transferred to the 2nd Stage recycle bin.

You cannot remove items from 2nd stage Recycle Bin, unless you are a site collection administrator.

2nd Stage “Recycle Bin”

How to access 2nd Stage “Recycle Bin”.

Click on “Settings” icon in the top right side of the site.

Select “Site Settings”

If you’re in a sub site, you may need to navigate to the root of the site collection by clicking “Go to top level site settings” in the “Site Collection Administration” section.

From the “Site Collection Administration” section click “Recycle Bin”.


if you remove items from here, then you cannot restore..

Default Settings for “Recycle Bin”

Settings for the recycle bin are controlled at the web application level. This means the any changes to the default configuration need to be carried out via “Central Administration”.

To access the settings, from “Central Administration” click “Application Management” > “Manage Web Applications”, highlight the desired web application and from the Ribbon click “General Settings”

The recycle bin is enabled by default with an automatic deletion from after 30 days and an allocated storage amount for the 2nd stage is 50% of live site quota for second stage deleted items.

The “Delete items in the Recycle Bin” figure is a set number of days for both stages, if an item is deleted from the 1st stage after 15 days it will only be available in the 2nd stage for a further 15.


This means that with a site quota of set of 500MB,  250MB is allocated as storage for the 2nd stage recycle bin making a total space requirement of 750MB. The percentage range for the “live site quota” needs to be a figure between “1-500%“. Obviously this content lives in the same content database as the site collection so you need to consider this when estimating your capacity requirements.


If the 2nd stage recycle bin reaches its quota limit, older items will be overwritten to accommodate items moved from the 1st stage.

If a site is deleted, it will skip the 1st stage recycle bin and go straight to the 2nd.

A user will only see items they have deleted in the recycle bin.

There are no PowerShell cmdlets to configure the recycle bin.

If the recycle bin functionality is turned off, items are permanently deleted and can only be retrieved from a backup.

If you have not enabled site quotas, the 2nd stage recycle bin will have no space limitations


Changing the Distributed Cache Service from One Server to another

Not gonna make this a long one because things are really busy. If you are getting to this post you should have an idea what the Distributed cache service is all about, if not here is a summary…

The Distributed Cache service is either required by or improves performance of the following features:

  • Authentication
  • Newsfeeds
  • OneNote client access
  • Security Trimming
  • Page load performance

For an overview of the Distributed Cache service, see or in plain English

I have some SharePoint 2013 environments I use for demos and the likes. one such environment has 4 servers, on Domain controller, a VPN server for networking, another for SharePoint 2013 as a web front end and the last one a SharePoint 2013 server dedicated specifically for managing the Distributed cache service. Now I have inherited this particular set of environments from Microsoft with dummy content on so I don’t have to work too hard at developing features for demos and POCs. My lap top has a max 16GB RAM so running all 4 servers in my hyper v is very resource consuming so I needed to find a way of minimizing the RAM requirements so I could use the machines all together without compromising on performance.

Although not totally necessary to have the distributed cache on a dedicated server unless you have a large farm, I decided to remove the need for the dedicated Distributed cache server as the farm is for use of about 100 users. That would save me about 8gb RAM! So no need for a dedicated cache server. But I do need to preserve the data on there and somehow transfer it to somewhere else where there is a valid service for the distributed cache, available to consume the data, the other web front end perhaps? Correcto! And then remove the service from the dedicated server and put the beast to rest.

So in Lamen’s terms…

Web Front End with Distributed Cache Service (dedicated) = WFE-DC

Web Front End with The Rest Of the SharePoint Services available = WFE-ALL

Some constants –

WFE-ALL has App fabric installed, necessary for the Distributed Cache and firewall is deactivated for the domain or  allows inbound ICMPv4 traffic. If you need Windows Firewall, you can enable this in PowerShell with the Set-NetFirewallRule cmdlet. The name of the rule is “File and Printer SharePoint (Echo request – ICMPv4-In)”. Notice also that it doesn’t take a Boolean ($true), but rather the string “True” as an argument to the -Enabled parameter. Don’t forget to Import-Module NetSecurity first, though! See below…


By now you’ve figured we need to use our new best friend Powershell to execute this master plan. Get used to Powershell if you wanna be a good developer/ architect, it can save you time and effort!

The Distributed Cache is one greedy kid, consuming a max of 10% total memory resource on any server it runs. So be aware of this when allocating memory to the server hosting the  service.

For whatever reason you need to move the Distributed Cache Service in a SharePoint environment,  here’s the master plan….

1.   Add the Distributed Cache Service to the WFE-ALL server to create a Distributed Cache Cluster (Fancy eh?). You need somewhere to move the cache data to when removing the service from the WFE-DC, to avoid data loss.

2.  ‘Gracefully’ shut down the Distributed Cache service on the WFE-DC. This will automatically move over all the data to the WFE-ALL server which is now part of the cluster. Its a long process, expect it to take around 15 mins or more depending on the amount of data in there.

3.  Them remove the service from the WFE-DC and it’s all done.

Now would you believe me if I told you this can be accomplished with 3 lines of Powershell??? Check this out…

1.  On WFE-ALL run the following:


2.   On WFE-DC run the following:

Stop-SPDistributedCacheServiceInstance -Graceful

Wait 15 mins, pour a drink or make a coffee, whichever poison tickles you fancy and then check the service is operational in its new location. Also test microfeed update settings in newsfeeds, this will be a good indicator of its state.

Other stuff you might need to manage at a later date are changing the service account, change the memory allocation or repair the host:

Pretty simple stuff peeps?

Peace, Love and SharePoint!



SharePoint 2013 Search not provisioning correctly

Imagine one fine sunny day you built a new SharePoint 2013 Search Application, for a new server or an old one, and the rain came in the form of an error accessing the application after Central Admin stated clearly that it was created successfully. Here’s what you would be experiencing:

After creating the Search Service Application, the following issues arise:

  1. The search topology displays the following message: “Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
  2. The default content source “Local SharePoint Sites” is inconsistent. It doesn’t always appear after creation of Search, sometimes with start addresses of existing web apps listed already, other times not.
  3. Starting a full crawl results in stuck in ‘starting’.

So you can’t configure your search. In PowerShell, all search components are listed as available.

Event Viewer shows:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (cf15c8c7-1980-4391-bd97-17de75c4dd5d).

Reason: Failed to connect to system manager. SystemManagerLocations: http://sp2013/AdminComponent1/Management

Technical Support Details:

System.InvalidOperationException: Failed to connect to system manager. SystemManagerLocations: http://sp2013/AdminComponent1/Management—> System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://sp2013/AdminComponent1/Management/NodeController that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace:

   at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)

   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)

   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)

   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)

   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)

   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)

   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)

   at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

   at Microsoft.Ceres.CoreServices.Services.Node.INodeControllerManagementAgent.get_NodeName()

   at Microsoft.Ceres.CoreServices.Tools.Management.Client.AbstractSystemClient.TryConnect(Uri nodeManagementUri, ICollection`1 locationsToTry, ICollection`1 triedLocations, ICollection`1 nodeSystemManagerLocations)

   — End of inner exception stack trace —

   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()

   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

After much digging and playing around, it seems this error goes away if I changed the app pool the search was running under to the SharePoint Web Services Default. But this is not what we want, Search should run under its own app pool. So after much more digging, I discovered that this is another bug I have found in SharePoint 2013, fixable by applying the following hotfixes:

Give the server a good old reboot and things should work fine. That’ll save you a few days of trouble.

Peace love and happiness!

SharePoint 2013 Search Service Application Configuration

A lesson learned when provisioning the search service application. I deleted the default one created using the config wizard and created a new one to run under its own application Pools. After which i received this error when trying to manage the application:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ‘bae8d161-c132-4570-aa0d-57baf6cf45h6’ in search application ‘Search Service Application 1’ is in a good state and try again.”

I was unable to start any crawls as a result or view content sources.

The search services were all started correctly but in the Application Services window it showed “Error”.


I fixed it by changing the properties of the application so both Search Admin web service and Search Query and site settings would run under the SharePoint Web Services Default App Pool. After an IIs reset my Search Service Application worked fine.

Hope it helps someone.

Network Discovery settings not sticking?

Apologies for the absence peeps, I’ve been very busy building servers and creating new Powershell scripts to facilitate my newest experiment: Installing and Configuring SharePoint 2013 on multiple servers in a mixed topology using only Powershell in a hands off approach. I will blog about it once I have finished my findings so hold tight!

Ok so I just have to write this up as I also use this blog to store valuable information I will likely need in the future, before I forget it .I’m configuring Windows Server 2012 environments and I’m trying to add them to my newly created domain. I know I need to enable network Discovery in the Network and Sharing Center (Control Panel–> Network and sharing Center–> Change Advanced Sharing Settings). But turn these on and as soon as you click ok, the settings revert back to their original state.

This issue will occur if the dependency services are disabled. Please make sure the following services are enabled and running:

-DNS Client
– Function Discovery Resource Publication
– SSDP Discovery
– UPnP Device Host

If this fails, check your firewall settings but it worked for me.

iOS and Microsoft Office – What Microsoft had to say

Whilst attending a SharePoint Online conference at the Microsoft Offices In Reading, i asked one of the officials whether there would be better Office for IOS in this or the next release of Office?

His answer went something like this:

We love windows, but we are not against building on other platforms in fact we’ve made Office for Mac for over 25 years. We are still in that gold rush period – platforms are changing fast and when platforms change there is significant work that needs to be done on our side – one example on Mac was the change from Cocoa to Carbon and deprecating backwards compatibility between OS9 and OSX. That sort of change meant we had to cut features from Office 2008 just before release and it took us till 2011 to get back to parity.
The iPad was released AFTER Office 2010 went RTM. Hard to believe. It has been widely used as a content consumption device and we want to support that. We also think the form factor is great for some light productivity needs such as reading,  email, videoconferencing and note taking.
We will have great Office experiences available on iOS and Android. We think HTML5 web apps, optimized for modern devices are a great combination. Using web apps means you can have a near native experience, keep your data secure without requiring jailbreaking your device, using developer units, or third party device management solutions that have very questionable support from the device manufacturer
Also web apps help us get ready for the next big thing without having to predict it. Over time, open platforms like HTML5 will win out over walled gardens – particularly if you are envisioning a multi-platform future, but still want consistency of experience for your users. Also, walled gardens you are giving up a fair element of control.
But we aren’t totally there yet with HTML5. There are still some use cases for native apps – particularly when you want to take advantage of hardware features such as cameras, USB drives or ink style input.
Well there you have it, another indefinite answer. The meaning in my opinion is there seems to be some minimal support for iOS, the main platform is still the Microsoft platform, until Apple stabilise the continual changes they make to their platform, Microsoft will be holding out on fully supporting the platform. Web apps seem to be the only way forward with improving support for iOS.

The Art of Installing SharePoint 2013 in a 3 Tier Topology- Part Three

So you’ve got your Active Directory Server up and running and SQL server 2012 is configured and good to go. If not see my previous posts for how to go about this Lets install SharePoint 2013 on your Web server. One thing to note is that my web server on which I am installing SharePoint 2013 will also act as my application server. My environment is not for client use as of yet so I don’t need a separate application server. If you have a client requirement for this type of topology, then by all means separate it out.

First the Requirements…

  1. You have an active and fully configured Active Directory.
  2. You have a SQL 2012 Server fully updated and configured, with the correct permissions set up for SharePoint required service accounts. See my previous post for this.
  3. You have all your service accounts created in Active Directory, I’ll cover this below.
  4. All servers in the topology are connected to the same domain.
  5. Your web/application server on which you are installing SharePoint 2013 has all required software and updates applied.

This post assumes you have all the above sorted before you install SharePoint 2013. Remember I am using the hyper V service to manage my servers and they are all running on a Server 2008 Guest OS.

Service Accounts

Why do we need these service accounts? Let’s thing separation of data. When it comes down to the nitty gritty and there needs to be “physical” boundaries between data you’ll want to use different service accounts. Think about search content access, user profile data etc. Custom Database Names
is a roundabout way pro for using separate service accounts and really is a point towards not using the Service Application wizard. It goes hand in hand that by not using the wizard you can use your own service account for the application and therefore being able to name the databases that get created when configuring specific Service Applications. When not using the wizard and using your own service accounts it lets you dictate what names most Web Apps are called as well as what services run under them. Call it a control thing! Separate service accounts mean multiple points of redundancy. Just as multiple accounts could be failure points. They are also redundancy levels.  Think if you had all your services running under the same service account. What if that account went bad, password expired etc. All your services go down. Now think if you had all your proper service accounts structured out maybe just search goes down but the rest of your farm and access to its features is still up.

With the new feature of managed accounts in SharePoint 2010 we can now set credentials and forget about them.  We can now set SharePoint to manage the passwords of our Service Accounts (yes that can be scary) but some of that risk is taken out of needing to worry about the passwords. Least Privileges basically means that you can manage and control the exact level of permissions that SharePoint can operate under. Search on “SharePoint Least Privileges” it will give you a good understanding of just how lean you can run SharePoint and still have all things work correctly. Ok let’s vamoose…

You need at least the following service accounts created in AD to successfully install SharePoint 2013:

SQL Server Service Account, e.g. sqlSvcAcc (If you have been following my previous posts, this has already been created and assigned permissions on the SQL server)

SharePoint Setup Administrator, e.g. spAdmin

SharePoint Farm Account, spFarmAcc

In SharePoint 2013 these accounts will fall under the managed accounts where you control the ability for passwords to expire or whether users cannot change their passwords. I always use in my development environment the options “User cannot change password” and “Password never expires”.

SQL Server Service Account

Permission are assigned automatically during installation of SQL Server 2012. The SQL Server service account should be a domain account and is used to run SQL Server.

SharePoint Setup Administrator

You need to manually assign permissions for this account. The setup administrator is used to install SharePoint 2013. The SharePoint 2013 setup administrator has to be a member of the administrators group on every server SharePoint should be installed. This account also needs the securityadmin and dbcreator and sysadmin (If creating a development environment so you can have only 1 account to administer Windows Server, SQL Server and SharePoint) role in SQL Server.

Farm Account

Permissions are automatically assigned by the SharePoint 2013 setup administrator so you don’t have to do it.

The farm account is used for the following things [1]:

“Configure and manage the server farm.”

“Act as the application pool identity for the SharePoint Central Administration Web site.”

“Run the Microsoft SharePoint Foundation Workflow Timer Service.”

See the Microsoft site for recommendations for service accounts:


In addition to the main accounts you need a separate account for each service application you intend to run as well as:

Application pool account

The application pool account is used for application pool identity. The application pool account requires the following permission configuration settings:

The following machine-level permission is configured automatically: The application pool account is a member of WSS_WPG.

The following SQL Server and database permissions for this account are configured automatically:

  • The application pool accounts for Web applications are assigned to the SP_DATA_ACCESS role for the content databases.
  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the farm configuration database.
  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the SharePoint_Admin content database.

Default content access account

The default content access account is used within a specific service application to crawl content, unless a different authentication method is specified by a crawl rule for a URL or URL pattern. This account requires the following permission configuration settings:

  • The default content access account must be a domain user account that has read access to external or secure content sources that you want to crawl by using this account.
  • For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.
  • This account must not be a member of the Farm Administrators group.

Content access accounts

Content access accounts are configured to access content by using the Search administration crawl rules feature. This type of account is optional and you can configure it when you create a new crawl rule. For example, external content (such as a file share) might require this separate content access account. This account requires the following permission configuration settings:

  • The content access account must have read access to external or secure content sources that this account is configured to access.
  • For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.

Excel Services unattended service account

Excel Services uses the Excel Services unattended service account to connect to external data sources that require a user name and password that are based on operating systems other than Windows for authentication. If this account is not configured, Excel Services will not attempt to connect to these types of data sources. Although account credentials are used to connect to data sources of operating systems other than Windows, if the account is not a member of the domain, Excel Services cannot access them. This account must be a domain user account.

My Sites application pool account

The My Sites application pool account must be a domain user account. This account must not be a member of the Farm Administrators group.

The following machine-level permission is configured automatically: This account is a member of WSS_WPG.

The following SQL Server and database permissions are configured automatically:

  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the farm configuration database.
  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the SharePoint_Admin content database.
  • The application pool accounts for web applications are assigned to the SP_DATA_ACCESS role for the content databases

Other application pool accounts

The other application pool account must be a domain user account. This account must not be a member of the Administrators group on any computer in the server farm.

The following machine-level permission is configured automatically: This account is a member of WSS_WPG.

The following SQL Server and database permissions are configured automatically:

  • This account is assigned to the SP_DATA_ACCESS role for the content databases.
  • This account is assigned to the SP_DATA_ACCESS role for search database that is associated with the web application.
  • This account must have read and write access to the associated service application database.
  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the farm configuration database.
  • This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the SharePoint_Admin content database.

FYI the database roles mentioned above are created automatically during installation.

You will need additional accounts for each additional service application you install, see here for the Microsoft best practice plan for service accounts:

It’s impossible to define a real set of service accounts that could fit any scenario, from a small development farm to a huge multi-tier farm. Each environment is different and will require its own customised set of service accounts. The Microsoft best practices link is very detailed, but you need to use your initiative to decide, based on your requirements, which accounts to use and which not to use.

Ok let’s install SharePoint 2013:


Make sure you are logged on using the SharePoint Setup Administrator.
The installer will also configure the Windows Server Application Server and Web Server role.

I used this as a reference:

Run the installation application and you will be presented with the following screen (Excuse the quality of the images, I will get better ones and replace as soon as I can):

Click on the Install software prerequisites link to automatically install all the pre required software.

After the Install, the system needs to reboot. When this is done, start up the installation again and select to install SharePoint 2013:

Enter your License Key, Accept Microsoft’s terms and conditions and choose to perform a complete install:

Once the Installation is completed, close the installation wizard.  Select the check box “Run the SharePoint Products Configuration Wizard now” (default).

You will be presented with notification of services being restarted during the configuration:

Select to create a new server farm:

Enter the appropriate information. Be careful of using the correct server names. I kept getting a permission error when trying to create the farm. It look hours of investigation to realise that I was using the incorrect database name for my SQL server. My database server was called SP2013DatabaseServer but its FDQN was SP2013DBServer, thus I was getting permissions issues as there was no server with that name. Good old SharePoint, always giving us uninformative error messages! I had to use the IP address in the end to get it to work.

Enter a passphrase and now it down.

Pick your Central Administration Settings:

Double check your configuration:

Configuration proceeds:

Hopefully not after too many grey hairs you should have a successful configuration:

Then a browser window will open with the following page, select to ‘Start the Wizard’ to configure the farm:

You will be asked to select the services you require to run in the farm as well as the service account. You can create a new one (needs to be in AD first) or select from the list but you can only select one for all of the services. I had to go back and manually change the service accounts for each of the service applications…boring!:

Notice some new faces in the service applications?

Then we see this screen with the words which will become both an annoyance and a joy for you as you will be bombarded with it, at least they are apologising now:

If everything is successful you will get this screen:

And voila, your farm is created… now go create a web application and site collection and have a play! Good luck.

Next I will try to automate the install and config of SharePoint 2013 using Powershell for multiple server farm… exciting I know. Powershell and I have a fractious relationship as I don’t like dark screens, I’m a girl I like bright pretty things, but the new Powershell commands for SharePoint 2013 are doing their job in making my life much simpler, so I can handle a simple life, even though I have to occasionally use a black screen!

FYI If you followed these instructions you might not get internet access on your DB and Web servers. What happens is that when you configure your AD Forest, Windows 2012 automatically expects all Internet traffic should be rerouted to this domain and that the domain is able to serve as a gateway to the Internet, meaning the domain can (or will later) have a DNS Server. My guest OS is using a wireless connection which is shared between all the servers, when connecting the DB and web servers to the domain you have to enter an IP address as well as a subnet mask and connect your DNs server (AD server). Doing this immediately blocks the internet. I have yet to configure the AD server to route internet connections, and when I do I will post the solution or you can research it, if you require your servers to have internet access. I don’t require internet access as I want control over the windows update service. I’m not a DNs expert so will have to consult the experts on this.

That’s all for now, wow 3 posts in one day..

Peace Love and Happiness!