SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846 x704.

Search This Blog

Tuesday, October 27, 2015

The Trust Relationship Between This Workstation And The Primary Domain Failed

So every now and then, I've come across the error when trying to login to a server:

The Trust Relationship Between This Workstation And The Primary Domain Failed

There are a number of reasons this can happen - basically it means that the Domain Controller and the Server are not communicating. For example, if a domain controller goes down and the server brought up, it cannot communicate to authenticate the server in the domain. This can also happen when system recoveries are necessary or when restoring a Virtual Machine.

One method (though not the best) is to simple login to the server as an Administrator, go to the System Properties, leave the domain by specifying a temporary workgroup name (you'll need the AD Administrator account & password), reboot then join the domain again.

However, there are two better ways to do this by simply resetting the Server Password in Active Directory from the Server you are having issues with. Login as the Server Administrator then via a Command Line (using Run as Administrator), enter the following:

netdom.exe resetpwd /s:<AD server name> /ud:<user name> /pd:*

Where 'AD server name' is the name of the Active Directory server and 'user name' is an account (in format of domain\name) that has permssions in AD.

Note that when you enter this command, it will prompt for a password to the account you specified.

Alternately, you can use PowerShell:

Reset-ComputerMachinePassword [-Credential <PSCredential>] [-Server <String>]

Where 'PSCredential' is the login name and 'String' is the name of the domain controller. For more info on the PowerShell command, see here:

https://technet.microsoft.com/en-us/library/hh849751.aspx

Once either of these methods are used, I suggest rebooting the server - when it comes back up, login with a domain account.


Tuesday, October 6, 2015

Some interesting changes for SharePoint 2016

Overall, SharePoint 2016 is simply an upgrade to 2013. One significant change is that Server Roles must be assigned when installing (i.e. web front end, etc.) and the Distributed Cache role is also new (as a setting that is – 2013’s streamlined model accounted for this role though most folks didn't use it). It is clear that it will require a few more servers in your average farm.

There are some cosmetic changes to the site templates (they changed the header a little bit – site settings now in a new black bar at the top of the page):


Overall, the installation process and adding servers is pretty much the same. All of the service applications are the same – and surprisingly, PerformancePoint is still available (Microsoft hinted at dropping that two years ago). They did add a new service for Project Server (see below). Site deployment remains the same and templates are the same as 2013.

As for features, annoyingly, the Access App feature is automatically enabled meaning you have to turn it off it you don't want your users using that (the security issues around Access still remain). This time though, they did expand on the explanation of what it’s for (in 2013, it just said Access web app).

They have added some new ones (not sure if this represents a merge of Project Server but sure looks like it; since this is preview, they might not include these in the final):

  • Announcement Tiles - Enables Announcement Tiles feature and adds the webpart to the site.
  • Project Proposal Workflow - Provides a review workflow for managing project proposals.
  • Project Web App Connectivity - Provides the lists required within a Project Site for integration with Project Web App including issues, risks, and deliverables.
  • Project Server Approval Content Type - This content type is used by the Project Server Approval workflow
  • Project Web App Permission for Excel Web App Refresh - When this feature is active, users can refresh reports containing Project Web App data within Excel Web App.
  • Project Web App Ribbon - Contains the ribbon controls for Project Web App pages.
  • Project Web App Settings - Project Web App PMO Settings
  • Sample Proposal - Sample workflow for Project Server

The Services on Server has changed a bit too, in addition to the Roles, they’ve added a new Restart option and an indicator if the Service is in Compliance (not 100% on the last one, but would appear to be based on the Role of the server):



Probably the biggest changes is the new 2016 Hybrid Feature – this allows connection to Office 365 and OneDrive:
“With hybrid features, you can take a best-of-both-worlds approach by providing access to Office 365 productivity services and offerings directly within SharePoint Server 2016. To learn more about SharePoint hybrid solutions, visit the 'SharePoint Hybrid Solutions Center' (http://go.microsoft.com/fwlink/?LinkId=533372).”

So – there you have it! As the preview, Microsoft is usually around 3 months to customer release – I expect we’ll see the final in December!


Troubles installing SharePoint 2016

If you are working with the pre-release SharePoint 2016 preview, you may get an error when trying to install. The error in the System Event Application log - Event ID 5586 shows the error as:

Unknown SQL Exception 53 occurred. Additional error information from SQL Server is included below.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

There are a variety of reasons this may occur, most notable:

1) Not using a SQL Alias - this has been a problem will all SharePoint versions. If you attempt to use the SQL instance name it will work - sort of. If it is the default instance you might be OK but usually services like the User Profile will not. If you've not setup an alias before, the command is "cliconfg". Be sure to enable TCP/IP and Named Pipes (with TCP/IP as the priority).

2) An actual network problem - some have experienced this in networks where the DNS is flakey; often adding all of the farm servers to the Hosts file (on all servers) will correct.

3) Incorrect settings in SQL Server - if SQL is set to Named Pipes vs. TCP/IP, this will occur.

4) Something else - sometimes, simply re-running the installation will 'fix' the issue. I had this occur on a fresh system; I rebooted and ran again and the install completed.

Hope this helps!

Tuesday, September 29, 2015

Issues with SharePoint 2013 Search - Event ID 1357

New installation - first time I came across this issue and there's no excuse for it. Apparently one of the SharePoint updates (one can only assume) seems to drop the proper permissions within the Search environment and suddenly, you get no new crawls.

You will most likely get Warnings in the event application log for Event ID 1357. The message (cuttting it down to the relevant info):

A database error occurred. Source: .Net SqlClient Data Provider Code: 229 occurred 0 time(s) Description:  Error ordinal: 1 Message: The EXECUTE permission was denied on the object 'proc_MSS_CrawlAdmin', database 'DSNet_Search_AdminDB', schema 'dbo'., Class: 14, Number: 229, State: 5    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, 


Go to the SQL Server and check - the Search Service Account probably doesn't have the proper permissions on the Search Databases. In my case, I had ALREADY checked these and they were changed.

In a low risk environment, assign it DBO rights. For high risk, it must have Security Admin and DDL Admin rights. Alternately, you can grant the rights to that account via the Database > Security settings (granting execute to all of the Stored Procecdures).

Wednesday, September 16, 2015

SharePoint 2013 Search Crawler failing, Event ID 1400

You might come across this issue when setting up a new farm - the errors vary, but in the System Event Application log, you will begin seeing warnings with Event ID 1400.

The issue is that the Search Service account doesn't have the proper local secuity policies set. Most of us are familiar with setting:

  • Impersonate a Client After Authentication
  • Logon as a Service

However, unique to this account, it needs:

  • Adjust memory quotas for a process

If the account doesn't have Adjust memory rights, the 1400 error occurs and SharePoint will not crawl content.

To fix, simply search for "Local Security Policy" and open it. Expand the Local Policies then select User Rights Assignment and add the Search Service Account (and the Farm Account) to each of the above polices:


Run an IISReset on the farm then start a new crawl.

Wednesday, August 26, 2015

Creating a Failover Cluster in VMWare Workstation 11

How To Create A Failover Cluster using VMWare Workstation


So....I'd seen a number of posts on this and while I had tried it in the past, I always seemed to have issues when trying to create a Cluster using Workstation (ESX, etc. different story). The steps were always a bit vauge on one item or another and issues like the 2nd machine not starting, inability to validate the cluster, etc.

Here's the How To that works:

1) Power down both servers

Stupid suggestion right? Of course you should start with the servers off and anyway, most of the settings here would cause you to have to reset the server so....

2) Backup the VMX Files

Navigate to the folder where the first server is and find the <servername>.vmx file. Right click on the VMX file and send it to a zip file in case you need to restore it! Repeat for the second server.

Don't do this to your own peril.

3) Add a second NIC to each server

Likely when you created the server(s), there was only a single NIC adapter added and the cluster needs two (one for the network, one to communicate between the cluster servers). The first NIC created should be set to Bridged. 

From the VMWare Console, click VM in the menu then select Settings... to open up the Virtual Machine Settings. Click the Add... button to open the Add Hardware Wizard and select Network Adapter. Click Next >, select Host-only, leave other settings as is and click Finish.

When done, it should look something like this:


Note: If you don't do the Host-only setting, it won't work.

4) Create the Shared Drives

A cluster needs at minimum a Quorum disk (used to sync between the servers) and a data disk (you can add any number of disks as needed).

Create a new folder wherever you keep your VM's stored and call it ClusterDrives (or whatever name you want). On the 'first' server (whichever you pick as the starting point), add the Quorum disk (you'll repeat this process for each disk you add):

a) Open the VM Settings as above (when you added NIC's). 

b) Click the Add... button to open the Add Hardware Wizard

c) Click Hard Disk to select it and click Next > to display the Select a Disk Type page

d) Leave the type selected as SCSI then select Independent and Persistent as shown (we don't want them to be tempermental now do we?):



e) Click Next > to display the Select a Disk page:


f) You can choose the type of disk here - but for most cases, leave this as Create a new virtual disk (you'll have to do different on server 2) then click Next > 
g) On the Specify Disk Capacity page, select the disk size - for the Quorom disk (ONLY!), 512 is fine - click to select Allocate all disk space now and click to select Store virtual disk as a single file as shown:


Adding additional data disks for stuff like SQL, you obviously will use a more realistic size - like 100GB. However, be aware that I have had trouble trying to use the Multiple Files option for any size (to be expected - usually it would be SAN storage that is dedicated if you are seriously setting up for a production environment). 

h) Click Next > to open the Specify Disk File page:


This is where you control where the disk will be created - click the Browse... button and browse to the folder you created. 

Type in the name of the disk, for example QuorumDisk.vmdk:


WARNING: YOU MUST ADD THE VMDK EXTENSION OR VMWARE WILL CREATE IT WITHOUT THE EXTENSION AND RENDER IT UNUSABLE.

* Someone apparently thought that the name extension to the right was a 'suggestion'?

i) Click the Open button - when you return to the Specify Disk File page, the path should be shown instead of just the file name. 

j) Click the Finish button to create the disk.

Now repeat the above to create a Data disk. When you do that, the size of the disk should be 1GB at least though you can make it as large as you have capacity for. Be sure to name the disk file correctly (i.e. DataDisk.vmdk). You can add additional disks as well if you setting this up for SQL Server (i.e. Data Disk, Log Disk, etc.).

When you are done, the drives created will appear in the Virtual Machine Settings page:


Tip: Make SURE they show (Persistent) - if not, delete and create again.

Next, it is necessary to set the SCSI Controller for the disk(s) - fortunately, this is a LOT easier in Workstation 11 - click on one of the new hard disks created then in the properties panel on the right, click the Advanced... button:


On the Hard Disk Advanced Settings page, set the SCSI of the disk to use Controller 1 instead of 0 and pick which Disk number to use - in this case, SCSI 1:0 (Controller 1, disk 0):


Note: this is cool they made this available - in the past, it was all in editing (see below) - this ensures you will be able to designate the disks to a different controller - no fuss, no muss.

Repeat this for all the disks added - be sure to keep track of which disk is on which disk channel - they MUST match on the second server when you add the disks!

5) Add the Disks to the Second Server

Using the VM Settings for the second server, repeat the process to add disks - this time however, you will NOT create disks, you will simply select an existing disk:


After you have added the disks, select each and use the Advanced settings to change the SCSI Controller and disk numbers. Be SURE to match the first server.

6) Modifying the VMX Files

Next, it is necessary to update the VM server configuration file for each server. Navigate to the folder where the first server is and find the <servername>.vmx file. Create a second backup of the vmx file before you edit (you are on your own if you don't).

Right click and open this file with notepad.

Search for the disk settings in this file by searching for SCSI1 - this should bring you to the section where the cluster drives are defined (you can search for the file path or disk file name too). This should look similar to this:

scsi1.present = "TRUE"
scsi1.virtualDev = "lsisas1068"
scsi1:0.present = "TRUE"
scsi1:0.fileName = "H:\ClusterDrives\QuoromDisk.vmdk"
scsi1:0.mode = "independent-persistent"
scsi1:1.present = "TRUE"
scsi1:1.fileName = "H:\ClusterDrives\DataDisk.vmdk"
scsi1:1.mode = "independent-persistent"

The lines above are the only ones you need to check (you'll find a few others) - mainly to make sure that the 'present = "TRUE"' is, uh, present.

Yours MAY look a litte different, for example:

scsi1.virtualDev = "lsisas1068"

Might be:

scsi1.virtualDev = "lsilogic"

Just below these lines, add the following:

disk.locking = "false"
diskLib.dataCacheMaxSize = "0"

Without these last two lines, starting the VM will cause it to lock the drives and block the other server from accessing them. See the troubleshooting at the end.

Save the changes and exit Notepad. 

Now, Rinse & Repeat: Make the exact same changes to the second server vmx file. Cut and paste if you can (I do not know why but this made a difference - twice!). 

6) Format the Shared Disks on the First Server

Power on the first server where the disks were added. Login using an Administrator account then using Administrative Tools > Computer Management  > Disk Management, bring the disks "Online" then format them - assign the Drive Letter accordingly (i.e. Quorum disk = Q:).

* I can't explain the Disk Management console here so I am assuming you know it.

7) Add the Shared Disks on the Second Server

Power on the second server. Login using an Administrator account then using Administrative Tools > Computer Management  > Disk Management, bring the disks "Online". When you do this, they should pop right up with the proper names you assigned on the first server HOWEVER the drive letters will be different. Right click on each drive and change the drive letter to match the first server.

And at this point you are done - you now have a shared network with shared disks ready to install a Failover Cluster!

SOME TROUBLE SHOOTING NOTES:

Second VM will not start?

1) Check the vmx file and make sure lines:

disk.locking = "false"
diskLib.dataCacheMaxSize = "0"

were added.

2) If set, try changing the line:

scsi1.virtualDev = "lsilogic"

To:

scsi1.virtualDev = "lsisas1068"

Second VM can't see the drives?
Shutdown, restore the backup vmx file for the second server and repeat the process.

How to back out?

Shutdown both servers (force power off if necessary), restore the backup vmx file for each server and power on. This will NOT delete the virtual drives.

----------------------------------
Hey folks - we do this for a living - leave comments, subscribe and never hesitate to send a link around!




Tuesday, August 25, 2015

SharePoint 2013 Workflow Visio Visualization Error

After setting up SharePoint 2013, you may come across an error when trying to access Workflow Status that renders in Visio.

However, you might get a failure that will look something like this:



Love that kind of error "The server failed to process the request" really tells it all eh?

So, there's a few things that can cause this:


  • First verify that the Visio Service (Services on Server) is started
  • Next verify the Visio Service Application and Proxy was created (Manage Service Applications)
  • Next verify that the Visio proxy is connected to the Application (Manage Web Applications)
  • Last (and most common), check the ULS logs - very often this problem is simply a logon issue:



To correct the latter, simply grant the account access to the Content Database in question.


SharePoint 2013 Workflow Fails after applying post SP1 & CU's

Like many have found, there is a bug in the patches applied in SP1 and I believe one of the subsequent Cumulative Updates - the issue appears when a Workflow tries to start. Right out of the gate you get the nasty error message:



For search purposes:

Method 'StartWorkflowOnListItem' in type 'Microsoft.SharePoint.WorkflowServices.FabricWorkflowInstanceProvider' from assembly 'Microsoft.SharePoint.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublickeyToken=71e9bce111e9429c' does not have an implementation.

You will also see Event ID 1000/1025 errors complaining about the Service Bus in the Event Application Log.

Fortuately the fix is KB2880963 - you can download this from here: 

https://support.microsoft.com/en-us/kb/2880963

You can apply this patch and will not require a reboot or run of the Configuration (i.e. PSConfig).



Tuesday, June 30, 2015

SharePoint 2013 Apps Won't Load

While I've not come across this before when setting up the Apps, specifically the DNS either as a standalone domain or just using a CName record, I did encounter a problem on a local development environment - not sure if this is a 'fix' or simply something as a work around.

In effect, the DNS was setup with a domain of SP13TDevApps.com (and tested on the AD/DNS system) but when trying to add an App it returned "The page can't be displayed" even though the nasty URL (thanks MS) is indeed correct:


Everything was checked from both the DNS server and the server hosting SharePoint but nothing seemed wrong:


As a last thought, a ping on the server itself revealed that it was (as is generally normal) returning the IPV6 address:


Just as a guess, I tried adding SharePoint Server name and IPV4 address to the Hosts file on the server:


And viola:


Again, this is just the environment I was in and it is development as well so take the above with a grain of salt - however, it's a pretty painless thing to try if you come across this issue but remember, if it doesn't work, remove whatever you changed and check your settings again.


Thursday, May 28, 2015

SharePoint 2013 User Profile Synchronization No Endpoint - Event ID 6398


Having come across this error enough times (and tired of searching for it) - occasionally, you might see an error regarding the SharePoint 2013 User Profile Synchronization service. Noted as a Critical Error in the System Application Event log, it shows something like this:

The Execute method of job definition Microsoft.Office.Server.UserProfiles.UserProfileImportJob (ID f8a883d5-a63e-44b9-9ed8-90cdceebc96c) threw an exception. More information is included below.

There was no endpoint listening at http://sp13:5725/ResourceManagementService/MEX that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Notice that SP13:5725 (my server) will be different on yours.

As it turns out, this is usually caused by reboot in which the Forefront Identity Management (FIM) service has stopped (or didn't start). Using Administrative Tools > Services, scroll down to the FIM service and indeed you will see it will not be running:


Simple click the "Start the service" link to start it up. On next synchronization attempt, all should be good and the error should go away.


Monday, April 27, 2015

SharePoint 2013 My Sites: Could not load user profile

In a new or existing farm with My Sites setup, you might encounter that when accessing the my site, SharePoint generates the error "Could not load user profile".

There a number of causes for this, most notably if the User Profile Synchronization service isn't running (or has had a problem) or, as I have found, is often due to services.

The symption is shown when opening a My Site:

So, first thing to check is the UPS service and make sure it is running (both the service and synchronization service). Open the UPS Service Application and try executing a syncrhonization job (incremental should be good enough) - assuming successful, try the My Site again..

Still no luck? Seems every now and then SharePoint likes to stop a service, specifically the ForeFront Identity Manager service. Check this through Administrative Tools > Services:


Notice it is NOT running but IS set to Automatic - go figure. Simply click Start the service. Wait a few minutes and access the My Site again and all should be good!


SharePoint 2013 The trial period for this product has expired


So on an existing SharePoint Farm with a STATIC activiation key, I'm setting up a quick demo. Create a new site, all good. Edit the home page then try to publish and I get:

The trial period for this product has expired

Odd for sure - particularly with a Static key (which never expires). Since this farm has been running for quite some time, naturally, we looked into changes - other than a few recent updates (and don't you hate MS likes to stick a few for SharePoint in there?) nothing clear.

After much research, you can easily find a workaround for an actual Trial (with a new key):

http://social.technet.microsoft.com/wiki/contents/articles/26761.sharepoint-2013-and-2010-the-trial-period-for-this-product-has-expired.aspx

But this was obviously not our issue. The only 'change' was a rebuild of the search service - maybe the cause? Don't know...

However, finally found the fix using the PSConfig command - simply opening SharePoint 2013 Management Shell (running as Administrator!), ran the following:

PSConfig -cmd secureresources

After a bit, the process completed (took about 15 minutes):


Right after this, ran and IISReset and Viola - SharePoint 'all better'.

** Some folks said that running an IISReset is all that is required afterwards HOWEVER, in a multi-farm enviornment two other things may be required:
1) PSConfig should be run on all SharePoint Servers
2) A reboot MAY be required of the entire farm

Needless to say, if this happens, just hope you got an outage window handy!



Wednesday, April 15, 2015

SharePoint 2013 Restoring by Content Database Apps no longer work

A cautionary tale: Recently working with a guy that had an issue after doing a site restore from a production site to a development site that included both a site collection and the App site.

Once restored, site and app store came up just fine - except - oddly, any non-out of the box apps that were deployed no longer worked. Clicking on them immediately triggered a 404. A check in Fiddler verified that the URL's were indeed right.

Having walked in on the situation, we started looking for a cause. Oddly, dropping and re-adding the apps worked just fine. Started checking the apps out in the site and found that indeed all of the apps were there an registered. The only error generated (in the System Event Log) was "app principal was not found" indicating that the app wasn't registered. Checking everything, all GUID's were good and they did appear registered so what gives?

Minor detail: All of the app information (licenses, registration, etc.) is actually in the App Management Service database. When bringing over the content DB's, it is also necessary to bring this since the registrations are needed for the sites.

So - the simple answer is to be sure to restore Service Application databases when necessary, specifically the App Management Service and the Secure Store if there are connection apps defined there.

However, this is not without issues - if you are restoring only a single app, site collection, etc. and you have others that already exist, overlaying the AMS DB will break all existing sites. It would appear that there is only the manual fix of dropping and adding apps back to the given site. I have not found another workaround (if you know one, please comment!).

Monday, April 13, 2015

SharePoint 2013 - Failure to connect to Config DB

Further proving that the teams aren't coordinating....So you have a SharePoint server - all is well but then you see this (remember, this is 2013!):


While obviously this is 13 (and not 10), the issue is simply that the server cannot connect to the config database. In a production environment, you shouldn't see this but SQL Server 2012 has a nastly habit of not starting up on a reboot (even though set to Automatic):



In a dev environment, it happens a lot! If SP was working, that's the first place to check. Simply start the SQL Server and SQL Server Agent and SP should come right up.

Thursday, February 26, 2015

Visual Studio Project 'Consider app.config remapping of assembly' error

Working with various types of projects with SharePoint, it's likely you will come across this error:

Consider app.config remapping of assembly "Microsoft.SharePoint.Security, Culture=neutral, PublicKeyToken=71e9bce111e9429c" from Version "14.0.0.0" [] to Version "15.0.0.0" [C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Security.dll] to solve conflict and get rid of warning.

The particular assembly might be different depending on which ones you have added or included in the project (this is common since SharePoint 2013 has to support 2010). The fix is easy - open the app.config file in your project - by default it should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

The fix is to map the assembly by adding the <runtime> section below:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
  <runtime>   
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
          <assemblyIdentity name="Microsoft.SharePoint.Security" publicKeyToken="71e9bce111e9429c" culture="neutral"/>
          <bindingRedirect oldVersion="14.0.0.0" newVersion="15.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
</runtime>
</configuration>

Wednesday, February 18, 2015

SharePoint Search and Robots.txt - telling search not to crawl parts of SharePoint 2013

Much of SharePoint's workings should A) not be accessbile (i.e. Site Settings, etc.) and B) shouldn't be crawled for content purposes. For A, there are no canned solutions but in the past, I've created a master page the redirected unauthorized users and in SharePoint 2013 there are ways to reduce for users using the Limited-access user permission lockdown mode feature:

 Limited-access user permission lockdown mode

For B, it is recommended to add Robots.txt file that will tell search to skip areas in SharePoint as follows:

1) Use Notepad (or Notepad++) to create a new text file and add the following:
User-Agent: *
Disallow: /_Layouts/
Disallow: /search/
Disallow: /searchcenter/
Disallow: /Documents/Forms/ 

WHERE:

Entry                                       What it means
User-Agent: *                           Apply to All Users
Disallow: /_Layouts/                Block _layouts
Disallow: /search/                    Block default search
Disallow: /searchcenter/          Block enterprise search center
Disallow: /Documents/Forms/  Block forms (i.e. Edit.aspx, etc.) 

Apply the proper URL here for the name of your search site (i.e. Search, SC, SearchCenter, etc.). Save this file as robots.txt.

2) Move/copy this file to the root folder of the SharePoint site (as in c:\inetpub\wwwroot\wss\virtual directories\<port #>. Right click on the file and grant "Everyone" read access. ALTERNATELY, the file can be uploaded to SharePoint's root using SharePoint designer.

3) Open Central Administration and click on Application Management > Manage Web Applications.

4) Click the Web Application to select it then in the ribbon, click Managed Paths.

5) The 'Add a new Path' text box, enter in /robots.txt, change the type to be Explicit Inclusion and click the Add Path button.

6) Open up the SharePoint Management Shell or a Command window using Run as administrator and run IISReset.


SharePoint ULS Error UserAgent not available, file operations may not be optimized

ULS Error (repeating) in SharePoint 2013 shows:

UserAgent not available, file operations may not be optimized

A quick shout out to Richard Leeman for the fix - it means that the Blob Cache has to be cleared. Using PowerShell:

$webApp = Get-SPWebApplication "http://<Site>:<Port if needed>" 
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)

Tuesday, February 3, 2015

Using 'Run as administrator'

Working with Windows 2012/14, SharePoint 2013, Visual Studio 2013/14, etc. on a server, even though logged in with an Administrator account, the permissions in Windows are set so that 90% of the time, it is necesssary to right click on something and choose 'Run as administrator' to get the proper access.

This is really prevalent with SharePoint - from the Command Line to PowerShell to Central Administration, 'Run as administrator' is required.

While I got used to this, turns out the quick fix has been there all along!

The best is to adjust both Shortcuts (like Central Administration) and the actual programs themselves (like PowerShell and Visual Studio (devenv.exe)). To find the exe for a given program, right click on a shortcut and select "Properties" (if Properties is not shown, use Open file location to find the true shortcut). From the Properties window, look at the Target field - that will have the path to the executable or URL link (like CA).

Once you have the shortcut or exe, right click and select Properties - on the Properties pop-up, click the Advanced button then click the checkbox for "Run as administrator" then click OK to save the change.

NOTE: For some items, like DevEnv.exe you can only set the Administrator option on the SHORTCUT. Right click on the shortcut from the Start menu and Open file location. Once there, you can set the Administrator rights on the shortcut there.

From there on, no need to right click anymore!