SharePoint Me in the Right Direction

Does SharePoint 2016 support SAML 2.0

Mikelaughs — Fri, 17 Feb 2017 19:10:32 GMT

There may be some confusion, looking at all the public documentation for SharePoint, in regard to exactly what is and isn't supported in terms of SAML tokens. This article https://technet.microsoft.com/en-us/library/cc262350(v=office.16).aspx#plansaml states the following:

SAML token-based authentication

SAML token-based authentication in SharePoint Server 2016 uses the SAML 1.1 protocol and the WS-Federation Passive Requestor Profile (WS-F PRP). It requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. If you use Active Directory Federation Services (AD FS) 2.0, you have a SAML token-based authentication environment.

While this may seem straight forward for some, it doesn't explicitly say that SAML 2.0 is not supported. Thus the reason that this question was raised to the SharePoint Product team who writes the code for accepting SAML tokens. The results:

We support SAML 1.1 and below ONLY
We support SAML 1.1 with all versions of ADFS (2.0 through 4.0)

If SAML 2.0 will be supported in SharePoint On-Premise at some future time, it is not likely to be in any version that is currently available (2016 or before), but that would be going more into the realm of speculation. Probably the best that can be said is that at this time there are no official plans for supporting SAML 2.0 in SharePoint 2016.

SharePoint Management Shell- List out all authentication Providers for each zone in each web Application in your farm

Mikelaughs — Fri, 17 Feb 2017 16:51:51 GMT

You may find yourself hunting for the SharePoint Web application and looking through each authentication zone to find the ones associated with a certain Auth Provider. This can happen if you've ever tried removing a claims authentication provider, but the error indicates that it is associated with one or more web applications. The following script will give you the details you need: $webapps = get-spwebapplication foreach ($webapp in $webapps) { Write-Host "===================Start Web Application" $webapp.Name "=====================" -foreground Green; Write-Host "Web Application Name: " $webapp.Name; Write-Host "Web Application URL: " $webapp.URL; foreach ($zone in $webapp.IisSettings.Keys) { Write-Host "--------------------------"; Write-Host "Zone: " $zone -foreground Magenta; Write-Host "Authentication Provider:"; Write-Host "--------------------------"; Get-SPAuthenticationProvider -WebApplication $webapp -zone $zone; Write-Host "--------------------------"; } Write-Host "====================End Web Application" $webapp.Name "=====================`n`n" -foreground Green; } One additional thing to note here, is that this script can be modified to give you the following information about each extended and mapped zone (each mapped zone correlates to an IIS site with these settings): AuthenticationMode : Forms MembershipProvider : i RoleManager : c AllowAnonymous : False EnableClientIntegration : True ServerBindings : {Microsoft.SharePoint.Admini stration.SPServerBinding} SecureBindings : {} UseWindowsIntegratedAuthentication : True UseBasicAuthentication : False DisableKerberos : True ServerComment : SharePoint - 5555 Path : C:\inetpub\wwwroot\wss\Virtu alDirectories\5555 PreferredInstanceId : 479071364 UseClaimsAuthentication : True ClaimsAuthenticationRedirectionUrl : UseFormsClaimsAuthenticationProvider : True FormsClaimsAuthenticationProvider : Microsoft.SharePoint.Adminis tration.SPFormsAuthenticatio nProvider UseTrustedClaimsAuthenticationProvider : False UseWindowsClaimsAuthenticationProvider : False OnlyUseWindowsClaimsAuthenticationProvider : False WindowsClaimsAuthenticationProvider : ClaimsAuthenticationProviders : {Forms Authentication} ClaimsProviders : {} ClientObjectModelRequiresUseRemoteAPIsPermission : True UpgradedPersistedProperties : {} This can be done by using: -------------------------------------- foreach ($iissettings in $webapp.IisSettings) { IisSettings.Values

SharePoint 2013 Incoming Email - a discussion of some of the requirements

Mikelaughs — Mon, 08 Feb 2016 11:03:35 GMT

- Cross posted from my post on the SharePoint Team blog, where you'll find blogs from a great bunch of knowledgeable SharePoint support engineers. http://blogs.msdn.com/b/spses/archive/2015/03/04/requirements-for-sending-email-to-sharepoint-libraries-including-x-headers.aspx ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ There have been some questions around E-Mail requirements for sending email to a SharePoint list or library, and specifically around the need for the x-sender and x-receiver header fields. This is not intended to be a comprehensive list of all requirements, but rather an overview of the way we use x-headers and other unique or notable requirements for sending mail to SharePoint lists and libraries. More information about requirements not specifically cited here can be gleaned from the referenced RFC 821 and RFC 822 standards. We process messages sent to SharePoint lists via email, in three phases. 1. First is the SharePoint Email Engine, which consists of the functionality associated with the SharePoint timer job which fetches the email messages from the Windows SMTP service via the drop folder, and then converts each message into a stream for delivery to the appropriate list in the appropriate SPWeb. This functionality exists in private classes, so there is not a great deal of available information on the internals of this step. 2. The second phase is handled in the SPEmailMessage class. I have linked to the public MSDN information about this step. This phase consists of parsing of the message extracting the header, body and attachment components, and converting these to metadata and attachments to be added to the target list/library is done here. 3. A third phase handles the details of mapping the appropriate metadata and attachments to the library-type specific fields. X-Headers are typically used in processing SMTP mail from the drop folder. While phase #2 and #3 do not require the X-Headers, phase #1 does require them, and uses them for routing the message. Since the first phase is not publicly documented on MSDN I have attempted to sum up the requirements for this phase below, with additional, relevant information from phases 2 and 3. 1. Required fields include: ============================== Sender Header = "x-sender: " Receiver Header = "x-receiver: " Mail file Pattern = "*.eml" Message ID = "message-id" If there are no Recipients listed in the “x-receiver:” header field, no sender listed in “x-sender:” , or the x-sender header field is not present, we will fail processing the message and return an error with this verbiage in the ULS logs: ----------------------------------------------------------------------------------------------------------------------------------------- A critical error occurred while processing the incoming e-mail file The error was: Bad senders or recipients --------------------------------------------------------------------------------------------------------- Additionally, if the message header contains "X-AlertServerType" with a value = "STS" or "X-mailer" with a value = "Microsoft SharePoint Foundation 2010" the message is considered to be originated from SharePoint and will not be delivered to a SharePoint list. The behavior seen in this first phase is similar to the Exchange replay folder behavior noted here: https://technet.microsoft.com/en-us/library/bb124230.aspx The X-Header fields, including x-sender and x-receiver, used by SharePoint are described in more detail here: https://msdn.microsoft.com/en-us/library/ms526966(v=EXCHG.10).aspx excerpt: Using the SMTP Message Envelope Fields A summary of the use of x-sender and x-receiver from this article is included below: =========================================================================== The recipientlist field contains the e-mail address of each intended recipient. If the message was submitted over the network through the SMTP protocol, each recipient corresponds to a RCPT TO: protocol command. If the message was submitted through the local SMTP service pickup directory, each recipient corresponds to an x-receiver header at the top of the message file. You can alter this list when executing; for example, you can expand a custom distribution list by substituting the alias address with each member of the list. The senderemailaddress field contains the address of the message's sender. If the message was submitted over the network using the SMTP, this address corresponds to the transmitted MAIL FROM SMTP command. If the message was submitted using the SMTP service pickup directory, this address corresponds to the x-senderheader at the top of the message file. Note The recipientlist and senderemailaddress envelope fields and the various message header fields such as (urn:schemas:mailheader:) To, From, Cc, and Bcc are different attributes of the message. The SMTP does not use the mail header fields to route the message; it routes the message based upon the RCPT TO and MAIL FROM protocol commands if a message is submitted using the SMTP, or the x-receiver and x-sender headers if a message is submitted to the local SMTP pickup directory. The envelope fields are not transmitted or stored with the message and exist only for the message's lifetime in SMTP transport. =========================================================================== In addition to x-sender and x-receiver, we make use of and populate the messagestatus and arrivaltime x-header fields when picking up the message from the drop folder and delivering it to the appropriate list. These fields help to manage delivery failures, aborts, retries, etc. 2. In the second phase we follow RFC 821 for attributes like “MAIL FROM” (EnvelopeSender), or if not present, we fall back to RFC 822 “FROM” header if MAIL FROM is blank or not present. The same behavior applies to the RFC 821 “RCPT TO” and RFC 822 “TO” header fields, among others. In this phase - SPEmailMessage - we use RFC 821 when parsing other message header, body, and attachment components. The MIME parser used is a specific - and modified to suit SharePoint coding design - version of the Exchange EDGE server role MIME parser. Of note, a 4K header size limit is imposed by our implementation of the MIME parser. 3. Third phase (SP Email Handler) and additional information: ==================== Attachments - Invalid filename characters = "\\/:*?\"<>|#{}%~&" SharePoint List types supported for email NOTE: SharePoint has coded email handlers for the following SPListTemplateType types. · Announcements · Events · DocumentLibrary · PictureLibrary · XMLForm · DiscussionBoard · Posts

Mapping a drive to a SharePoint library (Connect to Server) from Mac OSX Finder does not allow drag and drop of files into a SharePoint document Library

Mikelaughs — Thu, 27 Aug 2015 14:02:00 GMT

If you have ever tried mapping a drive to a SharePoint document library, from a MacBook Air or MacBook Pro - essentially any Mac OSX 10 device, you have probably noticed that it doesn't work! My experience was with a MacBook Air and MacBook Pro, both with OSX 10. What you might not be clear on is - Why doesn't it work? or - Where does the problem lie, in SharePoint or in the Mac OSX? Pardon any misuse of Mac terminology here, as I live in Windows 99% of the time. This is a high level look at what's happening: The problem starts when you use the Mac OSX Finder, which is similar to Windows "Explorer.exe", to connect to a SharePoint document library. This is done by clicking on Go -> Connect to Server -> Add the path to the SharePoint document library like http://SharePointPortal/sites/MyTeamSite/MacFilesGoHere/ Once the mapped drive (Connect to Server) is connected and opened, you try to drag and drop files from your MacBook into the drive/location. This results in either no file being copied over, or a 0 byte file being copied into the library. Additionally, you will likely see the following error: Copy ----------- The Finder can't complete the operation because some data in "TheFileName.rtf" can't be read or written. (Error code -36) --------------------------------------------------------------------- This error may look familiar, as it's often seen copying to other devices or locations from Mac's Finder. In addition to this error, you will probably find that Finder is now hung in an infinite loop (making repeated unauthenticated requests and getting 401 authentication responses) or is generally just no longer responding. To recover from this, you may be able to use the "Unmount" command, or you may have to power down the device and restart it. So, what is the problem? The Finder uses User-Agent: WebDAVFS/3.0.1 (03018000) Darwin/13.4.0 (x86_64) The Finder attempts to do PROPFIND and PUT for additional files that it wants to copy to the library. For example, if I’m trying to copy a file called “MyFile.rtf”, these additional files include files like ._MyFile.rtf, ._., .DS_Store, etc. These requests all return 414 errors from SharePoint: HTTP/1.1 414 REQUEST URI TOO LONG X-MSDAVEXT_Error: 589924; The%20following%20file%28s%29%20have%20been%20blocked%20by%20the%20administrator%3a%20%2fsites%2fMyTeamSite%2fMacFilesGoHere%2f%2e%5fTheFileName%2ertf (decoded: X-MSDAVEXT_Error: 589924; The following file(s) have been blocked by the administrator: /sites/MyTeamSite/MacFilesGoHere/._TheFileName.rtf) Ultimately, Finder will either copy a 0kb file or no file to the document library because of this error. What's the cause? SharePoint was not built on top of Mac OSX obviously. The additional files that are so integral the way OSX, and more specifically, the way their HFS or HFS+ file system works, are not used in an NTFS files system and are not understood by SharePoint. SharePoint was designed to interface with NTFS directly when using "Open in Explorer view" and adding this functionality was no small feat. The fact is, HFS and NTFS are two completely different and privately controlled, proprietary file systems which work in much different ways. You can start to scratch the surface on understanding the HFS scheme and use of these additional files here http://lists.apple.com/archives/applescript-users/2006/Jun/msg00180.html. Further, SharePoint has not been designed to accept file names beginning with a dot "." and in fact is designed, since the days of FrontPage server extensions, to block them. Even if SharePoint was changed to allow the dot (.) prefixed file names, these additional “sidecar” files that Mac OSX Finder tries to add would be likely to interfere with advanced features like required properties, force checkout, event receivers, versioning, alerts, workflows, etc. So there would be a monumental coding and collaboration effort required, to allow these additional files to be added. Certainly, additional handling would have to be built into many areas in SharePoint for this to even begin to be feasible. This is not to say that SharePoint couldn't either strip out these files or build in support for them, but this would not only require close collaboration with Apple to properly handle the files, but also Apple would have to be willing to expend effort to work with the SharePoint product team to help them improve their own product, much in the same way the Windows OS team had to expend time and resources to allow the SharePoint Explorer view feature to come into being at all. Long story short, fixing this would not be up to Microsoft alone, and to do this fully (i.e. not using some reverse engineered, open source version) would require a joint effort and buy in from Apple to assist with the effort every step of the way, including their support should it break. What can I do? Right now, and in the foreseeable future, the best option is to not use the "Connect To Server" option of Finder in Mac OSX to try to copy files into SharePoint. The alternative? Use the browser. SharePoint 2013 allows you to drag files directly into the web UI from Finder (a file on your Mac). Just browse to the document library in the browser and drag files into the area indicated. You can also use the options in the web UI to upload files via the menu. With these additional options readily available, there isn't a really compelling need for Microsoft to take on the monumental effort of rewriting SharePoint to comply with a completely different file system and concept of file metadata, just so it can allow a third entry point for these types of files. And now you know why it doesn't work. It's not evil ;) , it's just different file systems with different schemes crashing into each other. It's a new day and I think we'll find we're moving away from the concept of mapped drives anyway, and toward more modern concepts like syncing and web driven, cloud enabled storage and management of files. A deeper look If you want to see what files, exactly, that the MacBook is trying to copy over, you can do two things:

use a web traffic analysis tool to inspect the traffic
format a thumb drive as Fat32 or exFat and plug it into your MacBook. Then use Finder to drag files over to the drive. Now take the drive back to windows (easiest way) and unhide hidden/system files. You’ll see all the additional files that were copied over to the drive along with the one file you selected.

exFAT: allows you to store files larger than 4 GB and can be read and written in Windows and OS X 10.6.5 and later. To analyze web traffic from the MacBook, I set up Telerik’s Fiddler on a Windows PC and enabled remote connections in Tools -> Fiddler Options -> Allow remote computers to connect, and set Fiddler to listen on port 8888. I then set up a web http proxy on the MacBook to point to the PC on port 8888. This allows me to load Fiddler on the PC and capture all of the traffic coming from the MacBook, including the conversation with the SharePoint server.

Playing Windows authenticated SharePoint 2013 Videos from a Mac OS X device and Safari browser - Solution

Mikelaughs — Wed, 21 Jan 2015 11:04:47 GMT

The Problem:

You are Unable to play videos from an authenticated (Windows Authentication) SharePoint site on a MacBook (OS X) running the Safari browser. This was reproduced on SharePoint 2013 by editing a page and selecting Insert -> Video -> From Computer.

The video may say “Loading” or may just never start playing.

What Gives?

On a Windows PC using integrated AUTH (i.e. logged into the domain): All that is needed to make this work in Safari is to enable BLOB cache on the web application (ref: Disk-Based Caching for Binary Large Objects in SharePoint Server 2010 (ECM)). This is because BLOB cache adds support for byte-range requests, but more on that later.

On Mac OS X: When using NTLM authentication the first request to the server will be responded to with a 401 “WWW-Authenticate: ” response, indicating that the request needs to authenticate using one of the listed methods. When the Safari browser on Mac OSX receive the initial 401 response to the video request, Safari sends a "Connection: Close" in the next GET request for the video.

This same problem is seen if you take the video outside of SharePoint and just place it on a plain old .aspx or other page type that you create and put into a new IIS site. The authentication fails when trying to get the video, even though you are able to authenticate and get the page.

Below is an example using the .aspx page I created and placed in an IIS site with Windows Authentication enabled and an HTML5 video tag:

First, we request the page:

--------anonymous Get request for page-----------

GET /pages/page1.aspx HTTP/1.1

Host: WebServer.contoso.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Connection: keep-alive

-----401 with allowed Auth types response from server---------

HTTP/1.1 401 Unauthorized

Content-Type: text/html

Server: Microsoft-IIS/8.0

WWW-Authenticate: Negotiate

WWW-Authenticate: NTLM

X-Powered-By: ASP.NET

Date: Fri, 04 Oct 2013 22:54:26 GMT

Content-Length: 1293

Proxy-Support: Session-Based-Authentication

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

--------GET request with NTLM stub-------------

GET /pages/page1.aspx HTTP/1.1

Host: WebServer.contoso.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Connection: keep-alive

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

------NTLM challenge response from server--------------

HTTP/1.1 401 Unauthorized

Content-Type: text/html; charset=us-ascii

Server: Microsoft-HTTPAPI/2.0

WWW-Authenticate: NTLM TlRMTVNTUAACAAAAFAAUADgAAAAFgokCz7/tVAyW0JkAAAAAAAAAALYAtgBMAAAABgLwIwAAAA9UAEUAUwBUADMAMgA2ADcAMwA2AAIAFABUAEUAUwBUADMAMgA2ADcAMwA2AAEAFABNAEkASwBFAEQARQBNADIAMwA0AAQAHAB0AGUAcwB0ADMAMgA2ADcAMwA2AC4AbABhAGIAAwAyAE0ASQBLAEUARABFAE0AMgAzADQALgB0AGUAcwB0ADMAMgA2ADcAMwA2AC4AbABhAGIABQAcAHQAZQBzAHQAMwAyADYANwAzADYALgBsAGEAYgAHAAgAq7/9vlTBzgEAAAAA

Date: Fri, 04 Oct 2013 22:54:56 GMT

Content-Length: 341

Proxy-Support: Session-Based-Authentication

Not Authorized

HTTP Error 401. The requested resource requires user authentication.

----------fully authenticated NTLM GET request----------------

GET /pages/page1.aspx HTTP/1.1

Host: WebServer.contoso.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Connection: keep-alive

Authorization: NTLM TlRMTVNTUAADAAAAGAAYAEAAAADmAOYAWAAAABQAFAA+AQAACgAKAFIBAAAUABQAXAEAAAAAAAAAAAAABYIIAIrY6OVFM5g5nl+qrMQcJpeDek9uIM5K6EqzQ4NNWJdkxhRg5j3wlhsBAQAAAAAAAKDoVb5Uwc4Bg3pPbiDOSugAAAAAAgAUAFQARQBTAFQAMwAyADYANwAzADYAAQAUAE0ASQBLAEUARABFAE0AMgAzADQABAAcAHQAZQBzAHQAMwAyADYANwAzADYALgBsAGEAYgADADIATQBJAEsARQBEAEUATQAyADMANAAuAHQAZQBzAHQAMwAyADYANwAzADYALgBsAGEAYgAFABwAdABlAHMAdAAzADIANgA3ADMANgAuAGwAYQBiAAcACACrv/2+VMHOAQAAAAAAAAAAVABFAFMAVAAzADIANgA3ADMANgB1AHMAZQByADEAcwBzAGMAaABpAGUAbQBtAGEAYwA=

---------200 OK and content response from server------------

HTTP/1.1 200 OK

Cache-Control: private

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Vary: Accept-Encoding

Server: Microsoft-IIS/8.0

X-AspNet-Version: 4.0.30319

Persistent-Auth: true

X-Powered-By: ASP.NET

Date: Fri, 04 Oct 2013 22:54:56 GMT

Content-Length: 628

------------------------------------------------------------------

Now, we request the video

------------------------------------------------------------------

----------Anonymous GET request for video------(Notice the "Range: bytes=0-1 header)

GET /content/BirthdayParty.mp4 HTTP/1.1

Host: WebServer.contoso.com

User-Agent: AppleCoreMedia/1.0.0.11G63 (Macintosh; U; Intel Mac OS X 10_7_5; en_us)

Accept: */*

Range: bytes=0-1

Accept-Encoding: identity

Connection: keep-alive

-----------401 WWW-Authenticate: NTLM response from server-----------(Safari on MAC apparently requires this first response to be a byte range response)

HTTP/1.1 401 Unauthorized

Content-Type: text/html

Server: Microsoft-IIS/8.0

WWW-Authenticate: Negotiate

WWW-Authenticate: NTLM

X-Powered-By: ASP.NET

Date: Fri, 04 Oct 2013 22:54:56 GMT

Content-Length: 1293

Proxy-Support: Session-Based-Authentication

…

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

…

----------Since no byte range response was sent, Safari sends a "Connection: Close"-------(Also notice that Safari has changed the user agent)

GET /content/BirthdayParty.mp4 HTTP/1.1

Host: WebServer.contoso.com

User-Agent: QuickTime/7.7.1 (qtver=7.7.1;cpu=IA32;os=Mac 10.7.5)

Accept: */*

Connection: close

--------401 response with auth types allowed from server--------------

HTTP/1.1 401 Unauthorized

Content-Type: text/html

Server: Microsoft-IIS/8.0

WWW-Authenticate: Negotiate

WWW-Authenticate: NTLM

X-Powered-By: ASP.NET

Date: Fri, 04 Oct 2013 22:54:56 GMT

Content-Length: 1293

Proxy-Support: Session-Based-Authentication

…

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

…

------------------------------------------------------------------

This is what Safari is apparently looking for in terms of a response:

-------------------------------------------------------------------

HTTP/1.1 206 Partial Content

Cache-Control: public, max-age=86400

Content-Length: 2

Content-Type: video/mp4

Content-Range: bytes 0-1/383631

Last-Modified: Tue, 15 Oct 2013 23:30:53 GMT

Accept-Ranges: bytes

ETag: "{35DF5330-208E-4900-A467-F6327DFC241B},1pub"

Server: Microsoft-IIS/7.5

X-AspNet-Version: 4.0.30319

SPRequestGuid: 2c0a4d9c-2c89-b0f8-a067-c5db7abeabf7

request-id: 2c0a4d9c-2c89-b0f8-a067-c5db7abeabf7

X-FRAME-OPTIONS: SAMEORIGIN

X-Powered-By: ASP.NET

MicrosoftSharePointTeamServices: 16.0.0.2120

X-Content-Type-Options: nosniff

X-MS-InvokeApp: 1; RequireReadOnly

P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"

Date: Tue, 15 Oct 2013 23:31:41 GMT

-------------------------------------------------------------------------------

There are several WORKING scenarios for playing videos from SharePoint in Safari on Mac OS X or Windows:

1. Safari for Windows – accessing SharePoint 2013 with NTLM (or basic, other) authentication: Requires BLOB cache be enabled on SharePoint web application.
Thanks to Kirk Liemohn for pointing out in his Blog, you need blobcache to be enabled on all WFE servers.

2. Safari for Mac – accessing SharePoint 2013 with ADFS claims authentication (or other SAML claim type auth): Requires BLOB cache be enabled on SharePoint web application.

3. Safari for Mac or PC accessing a page on an IIS site with HTML5 video tag, anonymous access allowed: works out of the box – IIS 7.5+ support byte-range natively.

4. Safari on Mac or PC accessing Office 365 : Works out of the box. BLOB cache is enabled, and federated claims authentication is used in this scenario so no 401 challenge response is returned.

5. Safari on Mac or PC accessing SharePoint 2013 with anonymous enabled on asset library: Works, because of an odd behavior in that a) Safari does not send an anonymous access token like IE does on first request, so we return a 401 (Remember that anonymous is still authenticated using the IUSR account, so the anonymous token is still needed) B) When Safari responds with another GET request with the “Connection: close” header, we send the video file anyway in response, resulting in the file being available and playable in the browser.

So, from the above scenarios, and there may be more not addressed here, the overriding themes are:

- BLOB cache should be enabled (SharePoint BLOB cache supports serving byte-range requests).

- Safari expects and requires a byte-range response from the server. If one is not received, it sends a “connection: close” header in the next request.

Knowing what Safari is looking for in the response, and considering NTLM protected files will always return a 401 challenge response to an initial GET request, there really isn’t a change that I can see on the SharePoint side that will fix this. The server must respond to unauthenticated requests with a 401, when NTLM windows authentication is used.

Further, Safari on Mac with Kerberos authentication – We run into a similar issue as we do with NTLM because it seems that Safari on Mac doesn't send the Kerberos token with the initial request. While a Windows client will send "Authentication: Negotiate YIIGPg" with the first request each time, the Mac and Safari do not. I don't know if this is something that can be changed in OS X or Safari, to allow it to send the Kerberos ticket with the initial request, or if this is a limitation of Mac/Safari. If this were to be corrected, and the Mac is able to send the Kerberos ticket with the first request for the video file (should already be authenticated when accessing the page), then it would not be prompted with the 401 challenge, then the videos would work as expected.

What can I do?

First, turn on BLOB cache on your SharePoint server or make sure if you are running a pure IIS site (no SharePoint), that you are running IIS 7.5+. This will fix most Safari on Windows scenarios.

For Safari on MAC OS X, A couple of options are:

1. Use Forms based Authentication

2. Use Federated Authentication (such as ADFS)

3. Use a SSO (Single sign-on) server to broker authentication to the back end SharePoint servers

4. Allow anonymous access on the asset library

5. Request a change to Safari’s reaction to a 401 “NTLM challenge response” on initial video byte-range request, so that it doesn't send the "Connection: Close" if the 206 is not immediately returned.

SharePoint 2013 Profile Pictures no longer display in MySites after moving MySite URL or changing web applications

Mikelaughs — Tue, 14 Jan 2014 11:20:00 GMT

You may have run into this innocently enough, just trying to get a better URL for your MySite users. Or you have migrated and, for whatever reason, had to use a new URL for MySites.

For example: your MySite Host was http://portal.company.com and you have changed it to http://personal.company.com. Any change to the URL will cause the issue.

Once you migrate your MySite host to a new web application with a new URL or maybe just unextend/re-extend the web application to a different URL, you will notice that your user's profile pictures are no longer accessible, and look like this:

The Cause:
-----------------------
When you import pictures from Active Directory and run this command:

Update-SPProfilePhotoStore -MySiteHostLocation http://MySiteHost -CreateThumbnailsForImportedPhotos $true

All of the imported pictures that are currently in the metaverse get thumbnails generated and placed in this location:
http://MySiteHost/User%20Photos/Profile%20Pictures/

The location of the _MThumb.jpg that gets generated, is stored as a PictureURL property in the user’s Profile.

Incidentally, the _LThumb is the one used on the MySite “About Me” page, while _MThumb is the URL that gets stored in the profile properties.

Now that the MySites are hosted under a new URL, the old URL location of the profile pictures is not valid. Running another profile sync and running the Update-SPProfilePhotoStore command again to populate the thumbnails does not bring the pictures back, and you will see errors like this in the Application log in Event Viewer

Source: FIMSynchronizationService

Event ID: 6110

The management agent "MOSS-UserProfile" step execution completed on run profile "MOSS_FULLIMPORT_78fc6e7d-92a5-421a-a2f0-79a4250f42f3" but the watermark was not saved.

Log Name: Application

Event ID: 6803

Level: Error

The management agent "MOSS-UserProfile" failed on run profile "MOSS_FULLIMPORT_78fc6e7d-92a5-421a-a2f0-79a4250f42f3" because the server encountered errors.

Log Name: Application

Event ID: 6801

Level: Error

The extensible extension returned an unsupported error.

The stack trace is:

"System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.10.103.219:8000

at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)

at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)

--- End of inner exception stack trace ---

at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)

at System.Net.WebClient.DownloadData(Uri address)

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.DownloadPictures(ProfileChangeData[] profiles, Boolean delayErrors)

at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData)

Forefront Identity Manager 4.0.2450.49"

As well as ULS errors like this:

01/13/2014 15:04:50.00 miiserver.exe (0x138C) 0x1B54 SharePoint Foundation General adyrv High Cannot find site lookup info for request Uri http://sp:8000/User Photos/Profile Pictures/user2_MThumb.jpg.

Solution:

----------------------------------------

To correct this problem, you will need to re-base all of the profile picture URLs stored in the users’ profiles. I have seen a very compelling powershell method for this, using some good logic here, but there is an easier and completely out of the box way of doing this.

We will use our handy Update-SPProfilePhotoStore command again, but this time, for a different purpose.

Update-SPProfilePhotoStore -MySiteHostLocation -OldBaseUri -NewBaseUri

In my test example, I moved my mysite host from http://sp:8000 to http://sp:8001, and this is the command that I ran:

Update-SPProfilePhotoStore -MySiteHostLocation "http://sp:8001" -OldBaseUri "http://sp:8000/User Photos/Profile Pictures/" -NewBaseUri "http://sp:8001/User Photos/Profile Pictures/"

UPDATE! I recently did some deeper investigation into this command and found that you don't need to specify the library or folder name here. PowerShell won't complain, but it also doesn't care. The values of the Library and Folder names (/User Photos/Profile Pictures/ for English-US language webs) are hard coded in the product and cannot be changed. The command should look like this:

Update-SPProfilePhotoStore -MySiteHostLocation "http://sp:8001" -OldBaseUri "http://sp:8000" -NewBaseUri "http://sp:8001/"

NOTE: The purpose of the command is ultimately just to update the photo URLs to your new Mysite host location, and cannot be used to place them in a different relative path - i.e., a different library or folder name.

This will re-base all of your incorrect PictureURL properties in your user Profiles, and now all of the picture thumbnails which are already present in the MySite Host will show up properly.

Enjoy!

My Quick Deploy Job is causing 4958 and 6398 errors in the application log every 15 minutes

Mikelaughs — Mon, 23 May 2011 18:28:00 GMT

The SharePoint Content deployment topic has been well documented, but I recently ran into an issue which, I was surprised to find, was not covered.

In SharePoint 2007, when you set up a new Content Deployment Path, you automatically get a new job named “Quick Deploy job for Path ‘’

This job is designed to be used by content publishers of the source site, by using the Quick deploy option from a page that has been published (major version). Publishers access this option via:

Site Actions -> Show Page Editing Toolbar -> Tools -> Quick Deploy

Before your publishers can use this option, you must enable the quick deploy job. To do so, you would click the dropdown on the Quick Deploy job -> click Quick Deploy Settings -> Check the box [x] Allow Quick Deploy jobs along this path -> then click on Specify Quick Deploy Users

This will allow you to add users to the Quick Deploy Users [Limited Access] group on the site collection designated in the Deployment Path. Once you have done this, the Tools -> Quick Deploy option on a published page will no longer be greyed out for that user.

However, if no contributors have clicked Tools -> Quick Deploy, you will notice that the Job status in central administration shows the following for Last Run: Not Yet Run

You will also see the following errors in the application log each time the scheduled Quick Deploy Job is scheduled to run:

Log Name:      Application
Source:        Office SharePoint Server
Event ID:      4958
Task Category: Content Deployment
Level:         Error
Keywords:      Classic
User:          N/A
Computer:
Description:
Publishing: Content deployment job failed. Error: 'System.ArgumentOutOfRangeException: ContentDeploymentJobReport with ID '{00000000-0000-0000-0000-000000000000}' was not found.
Parameter name: jobReportId
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobReport.GetInstance(Guid jobReportId)
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.get_LastReport()
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.get_SQMDeploymentJobFlags()
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.CollectSQMData()
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.Run(Boolean runAsynchronously)
   at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobDefinition.Execute(Guid targetInstanceId)'

Log Name:      Application
Source:        Windows SharePoint Services 3
Event ID:      6398
Task Category: Timer
Level:         Error
Keywords:      Classic
User:          N/A
Computer:
Description:
The Execute method of job definition Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobDefinition (ID a2a9517b-f1e5-4d5e-803d-1eaae55cd84c) threw an exception. More information is included below.

ContentDeploymentJobReport with ID '{00000000-0000-0000-0000-000000000000}' was not found.
Parameter name: jobReportId

NOTE: the (ID ) in this event will be the GUID of your Quick Deploy Timer Job, which is different than the GUID for the actual Quick Deploy Job object.

Item of Interest:
===============
There is a list under your central administration site collection, located at http:///Lists/Content%20Deployment%20Jobs.
This list contains all of your content deployment job definitions.
Drop down on the Quick Deploy job for Path ‘your path’ -> View Item
You can use these properties to positively match the job with the GUID reported in the error, which will be shown under TimerJobId.
You will notice that the value for LastReportId is empty.

So, how do I fix this? Have a publisher quick deploy something in the affected Site collection, and voila, no more errors

Once a publisher who is a member of the Quick Deploy Users group uses the “quick deploy” option from the source site, the Quick Deploy job will complete successfully, and you will no longer see the errors. The Quick Deploy job status in Central Administration will update to Succeeded.

SharePoint Me in the Right Direction

Does SharePoint 2016 support SAML 2.0

SharePoint Management Shell- List out all authentication Providers for each zone in each web Application in your farm

SharePoint 2013 Incoming Email - a discussion of some of the requirements

Mapping a drive to a SharePoint library (Connect to Server) from Mac OSX Finder does not allow drag and drop of files into a SharePoint document Library

Playing Windows authenticated SharePoint 2013 Videos from a Mac OS X device and Safari browser - Solution

Server Error

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

Not Authorized

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

401 - Unauthorized: Access is denied due to invalid credentials.

You do not have permission to view this directory or page using the credentials that you supplied.

SharePoint 2013 Profile Pictures no longer display in MySites after moving MySite URL or changing web applications

My Quick Deploy Job is causing 4958 and 6398 errors in the application log every 15 minutes