Decreasing Indentation of Visual Studio Lines


There are a few articles already out on the Internet, but every time I need them, it takes me forever to find them (have you heard of bookmarks?). I decided to write my own post so I know I’ll always be able to find it.

Scenario

I’ve just copied and pasted about 100 lines of PowerShell code to a script I’m writing, but the indentation is way too far in for this. I’d love to just select all of it and use a key combo like indenting.

Solution

The solution is easy, just use this key combo

Shift + Tab

That’s it! Why can I never remember this? Now I don’t have to. I just need to remember I wrote this article.

KB2880994 Issue with Person Field – Fix


If your SharePoint environment is like ours and you wait a while to install hotfixes, Cumulative Updates, and Service Packs.

We recently discovered a problem with the following critical hotfix from Microsoft for SharePoint.

KB2880994

The issue we’ve run into and I believe there have been quite a few others also running into this is that in 2013 sites, when you attempt to Edit a list item that has a Person lookup field populated, upon editing, the field will go blank. If the user doesn’t realize it, they will save the list item and the person field is now blank. Data is lost.

The Assigned To field had a username in it, until clicking Edit.

The Assigned To field had a username in it, until clicking Edit.

I found the resolution was to Install the September Cumulative Update.

But, if you’re like us, and need more time to test the CU, you can simply install the below hotfix, which specifically addresses the issue.

KB2889884

There is no reboot required for this install and it will fix exactly this issue.

I hope this helps those of you having this issue. If you’re not aware of the problem, check the article, then check your farm.

SharePoint_Config_Log File Growing Too Large


If you manage both your SharePoint environment and your SQL environment, you may find that the SharePoint_Config_Log.ldf file keeps growing far too large. Here is a quick way to reduce the size of the file. There are other articles that explain how to do this for older versions of SQL server, but I found this one to work for me in my environment.

Environment

  • Windows Server 2012
  • SQL Server 2012 SP1
  • SharePoint 2013 Standard

Solution

  1. Run the SQL Server Management Studio 2012
  2. Select the SharePoint_Config database (you may have renamed yours)
  3. Open a new Query window
  4. Enter the following commands (Make sure you change the DB name if you don’t use the default name)
USE SharePoint_Config
GO
ALTER DATABASE SharePoint_Config SET RECOVERY 
SIMPLE
DBCC SHRINKFILE(N'SharePoint_Config_log', 1)
ALTER DATABASE SharePoint_Config SET RECOVERY 
FULL
GO

This will set the recovery mode of the configuration database to Simple which then will shrink the log file then it will reset the database back to FULL. I left mine as Simple as I have no intention of restoring my configuration database should there be an issue.

Sorry, we’re having trouble reaching the server


Recently we upgraded from SharePoint 2010 Foundation to SharePoint 2013 Standard/Enterprise. As with any upgrade there were some problems, but most were very minimal. This particular problem didn’t impact very many users, but was very frustrating.

Scenario

We had a list that we wanted users to submit a request to, this list we provided the user “Edit” permissions to, but no permissions to the rest of the site. When the user would attempt to complete the form they would get two errors. One during the form entry and one upon submission.

Error 1: Sorry, we’re having trouble reaching the server

Sorry_we're_having_trouble_reaching_the_server

This error is received in the “People Picker” fields of the list form. When attempting to enter a username or display name the user continually receives this message.

Error 2: The server was unable to save the form at this time, Please try again

The_server_was_unable_to_save_the_form_at_this_time

This error is received after completing the form and clicking the Save button

I started out as anyone does looking to Google (I even tried Bing) but all the articles I found that had a similar error message and scenario just didn’t solve the issue. Here some of the things I tried without success.

  • Reload the .NET HTTP Activation
  • Checked and re-checked Alternate Access Mappings.
  • I even tried adding permissions so the users could at least get the People Picker field to successfully run a user query, but I stil couldn’t save.
  • Backup/Restore of Site Collection to same location and different location

Solution

After all of that, I found the simplest of answers that just annoyed the crap out of me. I found that new site collections weren’t displaying the same issues so I decided I needed to start comparing the two. I started in the Site Collection Features menu and sure enough, there was my answer.

On the problem site collection I had the SharePoint Server Publishing Infrastructure feature Activated, which isn’t the cause of the problem directly, but it does by default enable the Limited-access user permission lockdown mode feature. Below is the description of the feature.

Limited-access_user_permission_lockdown_mode

 

There isn’t a lot of documentation on this feature, but when you Deactivate the feature, the issue goes away. It makes sense though that the issue would occur based on the description. It seems this is a security feature for public facing publishing sites so you aren’t accidentally sharing more data with anonymous users than expected, the problem is other users who not using anonymous access but do not have permissions to the top level site will also not be able to edit. Viewing is not affected.

This took me way too much time to solve, and I wish Microsoft didn’t make the default behavior to enable this feature, but such is the case. I hope this helps someone else out there. Good luck.

Sign In As Different User, Where’d You Go My Friend?


Those of us used to the SharePoint 2010 interface should be familiar with the Sign in as Different User option. It was a great feature that helped immensely with troubleshooting and developing in SharePoint.SignInDifferentUser

Low and behold, in SharePoint 2013, this feature is gone. Of course, if you’ve installed 2013, you already knew this. This is old (OOOOOLLLLLDDDDD) news. What might not be old news, is there is a simple way to force SharePoint to allow you to still use the feature. Here it is, in all it’s glory.

On any URL in your SharePoint farm, add the following to the end of the URL.

/_layouts/closeConnection.aspx?loginasanotheruser=true

So your URL will look like this: http://<URL>/_layouts/closeConnection.aspx?loginasanotheruser=true

You’ll then be presented the standard windows authentication box. Go ahead and login as your different user and you’re ready to go.

**WARNING** It seems the feature must have been removed due to caching issues. In testing on my own, I found Logging out using the SharePoint Interface or even closing the Browser tab does not clear the “different” user credentials, thus it is possible for the user who owns the Windows session to still be able to access a SharePoint site as the new account. Even after they have logged back in as themselves. The only remedy for this seems to be to close the browser itself. Even clearing the cache doesn’t always do it.

Be careful using this option. A better way might be to simply run Internet Explorer as yourself, then close when your’e done. Using the above method, though is a great way to test if there are issues with the users profile or settings in the profile such as Internet Explorer settings.

I hope this helps someone.

Who’s Managing Permissions?


Find_AccessRequestIt has been a while since I’ve posted anything, but that doesn’t mean I’ve been sitting around twiddling my thumbs all day. Here’s a quick SharePoint post. Stay tuned for more as we ramp up our new environment and we migrate to it. There should be some interesting stuff. (I hope)

Recently we’ve been getting requests from our messaging team (MS Exchange 2010) to remove/change e-mail addresses assigned in the Access Request field of our SharePoint sites as the domain has changed. This wouldn’t be an issue but we have 600+ Site Collections with 6,000+ individual sites. This of course means manually searching for the particular sites that have the offending e-mail address would be impossible. Thus, I have created a simple to use PowerShell script to iterate through every single SPWeb in the desired Web Application and return all Webs that have the user submitted e-mail address. Below is the full code.

**Note: I did not handle errors in this script. The most common error you will get is if you have Site Collections set to Read Only, or No Access. You will need to either reset their lock state or write logic to identify this and handle.

Step 1

  • Copy below code and save to file named Find_AccessRequest.ps1

clear
#End user is required to input Web Applciation, E-mail Address, and Export File Path
#Region User variable input
$inpWebApp = Read-Host "Enter the Web App Friendly Name"
$webapp = Get-SPWebApplication $inpWebApp
$inpEmail = Read-Host "Enter the e-mail address to search for"
$inpExportPath = Read-Host "Enter the path for the export"
#endRegion

#Gets the current date and time for the FilePath
$date = Get-Date -UFormat %y%m%d.%H.%M.%S
$path = $inpExportPath + "/" + $date + "_AccessRequest_" + $inpEmail + ".csv"

#Iterates through each site collection within the specified Web Application
foreach($spsite in $webapp.Sites)
{
	#Writes the current Site Collection to the console for troubleshooting purposes
	Write-Host "SC: " $spsite.URL

	#Iterates through each web within the site collection
	foreach($web in $spsite.AllWebs)
	{
		#Web must have permissions broken, request access enabled, and the e-mail must match the user input
		if( $web.HasUniqueRoleAssignments -and $web.RequestAccessEnabled -and $web.RequestAccessEmail -eq $inpEmail) 
		{
			#Writes the results to the console and exports to a CSV file
			Write-Host "	" -NoNewline; Write-Host $web.URL -BackgroundColor White -ForegroundColor Black
			Write-Output $web.URL | Out-File -Append -FilePath $path
		}
	}
}

Step 2

  • Run the file created in Step 1
  • Enter the following information (see screenshot below)
    • Web Application Name
    • E-mail Address to find
    • Path for export (do not include filename, the script will create the name)

Find_AccessRequest_Input

Step 3

  • As the script runs it will provide the following information on the console screen in real time (see below)
    • Site Collection URL
    • SP Web URL that has a matching e-mail address in the Access Request field (highlighted in White)

Find_AccessRequest-ResultsConsole

  • Now navigate to the Export location you entered. You should see a file with the following name:

yymmdd.hh.mm.ss_AccessRequest_<email address>.csv

  • Open the file. There will be a single column of data. The data will be each SPWeb that has the supplied e-mail address configured as the Access Request e-mail. It will only include Webs that have their permissions broken, which enables the web manager to configure the Access Request field independent of the parent site/web.

I hope this helps someone out there who needs to find an e-mail address in the Access Request field. I may at some point add to the script to allow for changing the address in bulk, but so far our need has only resulted in a few webs at a time.

As always, please a comment letting me know if this helped or if you have ideas to improve upon the script or for ideas for future scripts.

Thanks.

Issue: The search request was unable to connect to the Search Service


I installed Service Pack 2 on our SharePoint 2010 Foundation production farm last night and everything went as expected. The test scripts all passed which was awesome. I then proceeded to fix a few minor issues. One was an orphaned record alert in the Health Analyzer which we get from time to time and using the auto fix option within the alert has always fixed that issue which it did. I then proceeded to increase the page file size which I believe is the trigger that caused us to get the below error when I ran our test scripts and search had stopped working.

The search request was unable to connect to the Search Service.

Anytime search stops working in Foundation it’s a little freaky and I usually run to our DBA’s to make sure our DB permissions haven’t changed, but I decided to hold off and just got a hunch to do the following.

  1. Go to Central Administration > Upgrade and Migration > Review database status
  2. Ensure no databases require upgrade (Status should indicate “No action required”)
  3. Click on a content database
  4. Verify the correct search server is selected in the drop down
  5. Click Ok
  6. Repeat for all content databases

This resolved my search issue. It was as though the system lost it’s setting to identify which search server to use for the content database.

Disaster averted. Hopefully if anyone else experiences this issue this will help.