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.

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

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

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.

 

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.

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?

It 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)

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)

• 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.

Add Users in Bulk to SharePoint Groups

The other day I had a user ask to add 600+ users to a SharePoint group. Immediately I knew PowerShell was going to save the day, again. So, here is the script I wrote. You can download the full script along with a sample answer file. All I ask is that you let me know if you run into issues, and know that this script is provided as-is with no warranty or guarantees. I haven’t taken into account all possible errors so my error handling is very limited here.

**Typically it is recommended you use an Active Directory security group, but sometimes we have to make exceptions**

Don’t freak out because of the amount of code. Most of the code is building the menu to make it easy for even the least experienced PowerShell user to use. I write a lot of PowerShell scripts, so I don’t like having to open a script and review it to determine what/how to run it. Yes, I could build a help menu for the script, but I prefer a menu that will simply give me and others on my team the options to choose from. The screenshots below should help you understand what the code is doing. The help menu will bring you to this article.

STEP 1

• Run the file named Add-SPUser_Group.ps1 from the SharePoint CLI
• Enter a path to a directory to store the activity log (see below)

STEP 2

• Enter A at the menu (see below)

STEP 3

• Enter the path and filename of the .csv answer file (example answer file included in script download)
• Enter the URL of the site to add the users to
• Enter the Group ID

You can find the Group ID of a SharePoint Group by navigating to the Group in the browser. The ID is in the URL of the group

STEP 4

• The list of Usernames will be displayed to you (Usernames must be in DOMAIN\Username format in your answer file) (see below)

STEP 5

• You will see one of the following messages for each user in your answer file
  • “DOMAIN\Username” created and added to “Group ID” (displayed if a user account did not exist in the site. The account is added to the site, then added to the group)
  • “DOMAIN\Username” has been added to “Group ID” (displayed if a user already exists in the site and is added to the group)

STEP 6

• You will now be brought back to the main menu shown in STEP 2

Download Code

#Region Action Function
#Action taken via user input based on menu option chosen
Function Action ($result)
{	
	if ($result -eq "A")
	{
		AnswerCreate
	}
	if ($result -eq "B")
	{

	}
	if ($result -eq "?")
	{
		clear
		#Opens Default Internet browser and navigates to the below site that holds the instructions for this program
		Start-Process -FilePath "https://techchucker.wordpress.com/2013/09/17/addbulkspusergroups/"
	}
}
#endRegion

#Region PressKey Function

#User must enter any key to continue
Function PressKey
{
	Write-Host "Press any key to continue..." -ForegroundColor Black -BackgroundColor White

	$x = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp,AllowCtrlC")

	return clear
}
#endRegion

#Region WebInput Function
#Function to request web input from user
Function WebInput
{
	$inpWeb = Read-Host "Enter the URL of the site to add users to a group"

	return $inpWeb
}
#endRegion

#Region GroupInput Function
#Function to request SharePoint Group input from user
Function GroupInput
{
	$inpGroup = Read-Host "Enter the SharePoint Group ID to add users to"

	return $inpGroup
}
#endRegion

#Region AnswerCeate Function

#Function to take answer file and add multiple users to SharePoint Group
Function AnswerCreate
{
	clear

	#Imports user inputted answer file
	$userList = Import-Csv ($answerFile = Read-Host "Enter path to Answer File (e.g. c:\filename.csv)")
	$web = WebInput
	$group = GroupInput

	Write-Output $userList
	PressKey

	#Iterates through each record storing variables and executing user add
	ForEach ($user in $userList)
	{
		$validateUser = $null
		$LANID = $user."LANID"

		$validateUser = Get-SPUser -Identity $LANID -Web $web -ErrorAction SilentlyContinue #This will throw an error if the user does not exist

		if($validateUser -eq $null)
		{
			Write-Host $LANID "does not exist"
			New-SPUser -UserAlias $LANID -Web $web -group $group
			Write-Host $LANID "created and added to " $group
		}
		else
		{
			#Adds user/s to the SharePoint group
			Set-SPUser -Identity $LANID -Web $web -Group $group	
			Write-Host $LANID "has been added to "$group	
		}
	}	
}
#endRegion

#Region Menu Function

#Function to display the menu for the program
Function Menu
{
	Write-Host "Add Users to SP Groups in Bulk`n`n" -ForegroundColor Black -BackgroundColor White
	Write-Host "Choose the action you would like to perform shown below.`n`n"

	Write-Host "	A	-	Add users in bulk using Answer File`n"
	Write-Host "	?	-	Program Help`n"
	Write-Host "	Exit	Exits this program`n`n"
}
#endRegion

#Region Program Actions
$ErrorActionPreference="SilentlyContinue"
Stop-Transcript | out-null
$ErrorActionPreference = "Continue"

$logPath = Read-Host "Enter log path (c:\Logs)"
$date = Get-Date -UFormat %y%m%d.%H.%M.%S
$logFile = "\" + $date + "_AddUserGroup.txt"

Start-Transcript -path $logPath$logFile -append

do
{
	clear
	Menu
	$result = Read-Host "Enter your selection"
	if($result -ne "exit")
	{
		Action $result
		#Write-Host "Would you like to return to the main menu?`n`n"
		#$confirm = Confirm ($inp = Read-Host "Enter Y or N")
		$confirm = $True
	}
	else
	{
		$confirm = $false
	}
}
while($confirm -eq $True)

Stop-Transcript
#endRegion

ISSUE: KB2844286 RESOLVED with Update KB2872441

Microsoft has finally released an update to the KB2844286 issue with SharePoint. That update is linked below.

http://support.microsoft.com/kb/2872441

We have installed it in our DEV environment and have verified the issue is fixed within our farm. I have also confirmed that you must still have KB2844286 installed and then install KB2872441 as you will still need the other security related patches from KB2844286 (or KB2844285, or KB2844287 depending on OS)

My original post can be found below as I am still updating that post as I get updates.

ISSUE: KB2844286 Security Update on SharePoint 2010

ISSUE: KB2844286 Security Update on SharePoint 2010

Came in today to find the following error message showing up on seemingly random web parts and lists throughout our SharePoint 2010 Foundation farm. ULS Logs on the servers weren’t very helpful.

[This issue has been RESOLVED see updates below]

For the sake of search indexing, here is the text version of the error we are getting.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

We quickly tracked it down to a Security Update that was applied to our web front end servers last night. Check the OS below to find the KB update associated with your server.

Windows XP and Windows Server 2003

• KB2844285

Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1

• KB2844286

Windows Vista Service Pack 2 and Windows Server 2008 Service Pack 2

• KB2844287

This is in regard to the following Microsoft Security Bulletin for July 2013

Microsoft Security Bulletin MS13-052

As a temporary workaround, we found uninstalling the update (KB2844286) from your servers (all WFE’s and App servers) then performing an IISReset on the servers will resolve the issue. Several others have experienced this issue as noted in just one of many forums such as the one below

http://social.technet.microsoft.com/Forums/sharepoint/en-US/cc9a557b-93cd-40d5-965c-e0a2f107624d/unable-to-display-this-web-part-error-message-after-patch-kb2844286

If I find there is a solution better than uninstalling I will update this post to reflect that. As of right now, uninstalling this update is the best option.

[Update 7/16/2013 3:40pm]

It appears the error typically appears when a list or web part view has had the XSLT customized. At least in our Farm, that has been the common behavior.

[Update 7/17/2013 10:03am]

Not much of an update, but I’m awaiting contact from our Microsoft TAM to see about this issue. If we don’t hear from them soon, then we’ll be opening a ticket with Microsoft. Luckily we were able to work around the issue by uninstalling.

[Update 7/17/2013 12:50pm]

I just received confirmation from our TAM that Microsoft is aware of 2 issues regarding the patch noted in this article above. One of which appears to be the SharePoint issue we’re having.

[Update 7/17/2013 2:43pm]

Just spoke with our Microsoft Sr. Support Escalation Engineer assigned to our premier support ticket and here is their response (summarized).

“Our product group is currently working on the updated patch. We have no ETA for the new release at the moment.”

Looks like we wait then for a resolution.

[Update 7/17/2013 2:59pm]

One more confirmation from Microsoft Support and a link to the forum MS is using to track the issue publicly. No public information just yet beyond that, however.

“Both the SharePoint and .NET product groups are aware of the issue and they are in the process of fixing the patch.”

Follow the issue at this TechNet Forum

[Update 7/18/2013 9:24am]

So far I have heard of no updated patch being released yet by Microsoft. There were two MS Security Bulletin updates but it doesn’t appear they were related to this issue as they were for Bulletin MS12-006 and MS12-052.

[Update 7/21/2013 12:36pm]

Still no updated patch. Received an e-mail from our MS Support representative and they indicated they too have no ETA on any updates to the security patch. I guess I’d rather they take their time then rush an update out all to break something else. It would be a good idea if Microsoft were to either add a note to the update download page indicating the issue, or just pull the update altogether.

[Update 7/24/2013 8:28am]

I just got a message from our Microsoft Support representative and she informed me there is no update as of yet on a new download for the patch. No surprise there.

[Update 7/25/2013 7:50am]

As you can see from the comments that have arrived thus far, it appears Microsoft has provided a fix to the KB2844286 issue. We are in the process of testing it out in our DEV environment now. Let’s hope it fixes it and doesn’t cause more issues.

[Update 7/25/2013 8:22am]

I am at this point, comfortable with counting this issue RESOLVED. We’ve tested it in DEV and the solution resolves the problem and doesn’t seem to break anything else. We won’t be able to complete the resolution in our Production environment until after hours as we will have to re-install KB2844286 which will require a reboot and the patch requires at the very least an IISRESET.

Go to http://support.microsoft.com/kb/2872441 to download the update. Note: You will need to run an IISRESET for the update to take effect after installing.