To configure SharePoint to receive the url of the email alerts in ADFS zone format, it is necessary to execute the following PS:
$wa= get-spwebapplication “https://urlwebapp”
$wa.useExternalUrlZoneForAlerts = $true
$wa.ExternalUrlZone = “Intranet”
You can change the zone to set it within your ADFS zone in the SharePoint farm
Hi!
Today I bring a weird problem, but first I wan to explain the scenario where we have deployed our SharePoint farm.
It was a development server were we have configured NTLM in the default zone and ADFS in the Intranet zone, everything was working fine, but suddenly the search service stopped working in the ADFS zone while in the NTLM zone was still possible to extract search results.
It was a weird problem, we checked the logs and we received an error like the following:
Exception occured in scope Microsoft.Office.Server.Search.Query.SearchExecutor.ExecuteQueries. Exception=System.NullReferenceException: Object reference not set to an instance of an object.
Also we tried to use the SharePoint APIs using the following
http://url/_api/search/query?querytext=’something’&clienttype=’ContentSearchRegular’
http://url/_api/web/lists/getbytitle(‘Workflow Tasks’)/items
But we received an “exception ocurred” message
At this point, we were lost, so we started to watch the site collections listed in the farm, and we discovered that was listed one MySite Site collection as orphan. The site collection was inaccesible, also it has no properties listed, so we decided to delete the site collection by Central Admin. Unfortunately was not possible to select the site collection to delete, things continue weird…After trying to do this, we tried to delete the site collection by PowerShell, but was not possible to execute the get-spsite or remove-spsite against this site collection, it gave us an exception…
As a last option, we tried the following:
We detached the database which the MySites were stored from central admin and we executed the following to re-attach it again to SharePoint:
Mount-SPContentDatabase “<ContentDb>” -DatabaseServer “<DbServer>” -WebApplication http://SiteName
Once we attach it again, was possible to access to the site collection, also it was possible to delete it, but the most surprising thing it was that the search on ADFS it was working again!!!!
I don’t know the relation between ADFS and the orphan site collection but I spent a lot of hours to solve this problem. I anyone has a problem similar to that, try to detach the content database first, maybe it helps…
Recently, one of my colleagues was trying to connect to PowerBI with his own mobile phone, but when he tried to connect to the application, he was receiving the following error:
“Could not authenticate because your corporate SSL certificate is untrusted by this device”
How the device it is not joined to the domain it was firing this error. So I know that the problem was in the certificates, so the solution was pretty simple.
We needed to connect to the adfs url, and install all the certificates in the device. Once all the certificates of the ADFS were installed in the device it was possible to connect to the service with an untrusted device.
Hope it helps!
If you need to back up the rules of claim provider trusts and relying-party trusts in ADFS to store version control or to migrate rules to a new federation server, this is your post.
And here is the code I used:
# Guidance for this was found here: http://social.technet.microsoft.com/wiki/contents/articles/4869.ad-fs-2-0-how-to-migrate-claim-rules-between-trusts.aspx
#
# If you want the files saved somewhere other than C:Temp, you need to change the "$RulePath" lines below.
Import-Module ADFS
# Export the Acceptance Transform Rules for each Claim Provider Trust (except the AD one)
$claimTrusts = Get-AdfsClaimsProviderTrust | ?{$_.Name -ne "Active Directory"}
foreach ($CT in $claimTrusts) {
$RulePath = "C:Temp" + $CT.Name.Replace(" ","") + "-AcceptanceRules.txt"
(Get-AdfsClaimsProviderTrust -Name $CT.Name).AcceptanceTransformRules | Out-File $RulePath
$RulePath = $null
}
# Export all three types of rules for each Relying-Party Trust
$RPTrusts = Get-AdfsRelyingPartyTrust
foreach ($RP in $RPTrusts) {
$RulePath = "C:Temp" + $RP.Name.Replace(" ","") + "-IssuanceTransformRules.txt"
(Get-AdfsRelyingPartyTrust -Name $RP.Name).IssuanceTransformRules | Out-File $RulePath
$RulePath = "C:Temp" + $RP.Name.Replace(" ","") + "-IssuanceAuthRules.txt"
(Get-AdfsRelyingPartyTrust -Name $RP.Name).IssuanceAuthorizationRules | Out-File $RulePath
$RulePath = "C:Temp" + $RP.Name.Replace(" ","") + "-DelegationAuthRules.txt"
(Get-AdfsRelyingPartyTrust -Name $RP.Name).DelegationAuthorizationRules | Out-File $RulePath
}
Hope it helps!
Hi!,
Today I received a weird problem from my ADFS test environment, when I tried to navigate to the main SharePoint page it throws an error from the ADFS, so I decided to check the ADFS server to see what was the problem. To my surprise the ADFS service was stopped and when I tried to start the service it won’t fire up, things starting weird…
So after checking some things, I remember that this installation was made with the Windows Internal Database, so I decided to check the service, but it was also stopped, and when I tried to start it again it throws the following error message:
Service: MSSQL$MICROSOFT##WID
Domain and account: NT SERVICEMSSQL$MICROSOFT##WID
This service account does not have the required user right “Log on as a service.”
I don’t know if anyone of my company changed the policies or included the server in the policies overwritting all the policies previously configured by myself, but I had to solve this issue, otherwise I cannot continue with my tasks in the project.
To solve this thing, it was needed to change the Group Policy Management in the local computer, so enter to the local policy and navigate to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, User Rights Assignments. Edit Log on as a service and add the following groups:
IIS_WPG
NETWORK
NETWORK SERVICE
SERVICE
After this groups were added, run gpupdate/force on the server and then try to start the WID, in my case it was succesful so I was able to start again the adfs service and continue with my tests.
Hope it helps!
When troubleshooting ADFS server-side issues it can be useful to turn on ADFS Debug logging on the server.
To enable the ADFS debug event log, run the following in a CMD command prompt:
wevtutil sl “AD FS 2.0 Tracing/Debug” /E:true
Running the same command with /E:False disables the debug logging again.
After you have enabled it, reproduce the problem scenario and then run the following to dump out the log and convert it into XML format that you can then view:
To dump out the debug log after have been reproduced:
wevtutil epl “AD FS 2.0 Tracing/Debug” %computername%-ADFSDebuglogs.elf
To convert to it to XML
wevtutil qe %computername%-ADFSDebuglogs.elf /lf:True /f:xml
This summer it’s being a troubleshooting summer 🙂
This problem happened to us in our O365 environment, when we tried to Access to O365 outside of our network it shows an error message from the ADFS server, but when we tried to access to O365 inside our network all works well, so the problem begins weird.
At the beggining I was thinking in a problem in the ADFS Proxy, but suddenly I remember a recent post about renewing certificates:
https://sharepointrescue.wordpress.com/2015/07/20/o365-how-to-renew-your-certificates/
So the first thing was to check the certificates in the ADFS, and bang! Were out of date, so I decided to renew them manually and (most important), restart the AD FS Windows Service on the primary AD FS server.
After doing that the problem was solved and it was possible to Access to O365 inside and outside of our network.
Cheers!
Hi! Today I will talk about something that happens recently in one of our O365 deployments. We renewed our SSL certificates in our ADFS server, but when any administrator user Access to the O365 portal they were receiving the following alert inside the poertal:
Renew your certificates
One of your on-premises Federation Service certificates is expiring. Failure to renew the certificate and update trust properties within XX days will result in a loss of access to all Office 365 services for all users
Solution: This error can be caused if any of the three primary SSL Certificates that are required to federate to an external identity are nearing their experation date. In this case we know that this was a false positive, and automatically the certificate in the O365 tenant will be replaced, but some people at o our company were complaining about this message, so we decided to force to update the certificate.
So once again, we need some powershell to do that, let’s start
Open up the Windows Azure Active Direcotry Module for Windows PowerShell as an administrator.
Execute the following command: Connect-MsolService and enter your Office 365 administrator credentials
Execute the following command: Update-MsolFederatedDomain -DomainName yourdomain.com -SupportMultiDomain
Is it necessary to replace “yourdomain.com” with your federated domain. In case you have multiple domains you are federating with Office 365, add the optional -SupportMultiDomain parametyer as well.
Hope it helps!
By default the login page for the ADFS is very ugly, so this post will talk about how to customize it. This post will be divided into ADFS 2.0 and ADFS 3.0
Customize login page for ADFS 2.0
First of all, we have to do this modifications in the ADFS Proxy Server, so let’s begin:
Adding a Logo
Logo image file should be 600×100
Save image file to c:inetpubadfslslogo.jpg (or logo.png)
Open c:inetpubadfslsweb.config in notepad
Locate text
<!–
<add key=”logo” value=”logo.jpg” />
–>
Remove the “<!–” and “–>” to uncomment the section. Change filename to match the logo you saved.
Save file and close
Change the “Example” Instructions
Change the Instruction Text
<data name=”FormsSignInHeader” xml:space=”preserve”>
<value>Type your user name and password.</value>
</data>
Change the Page Title
Remove or Change the Hostname Header Above the Login Box
More information: Here
Customize login page for ADFS 3.0
To make this changes is pretty easy, and we will done them by Powershell!!
So, we need to enter into ADFS and open a Powershell CMD as Administrator, and type the following:
Import-Module ADFS
#This simply adds the ADFS commands to PowerShell. It’s necessary so the rest can run.</
SetAdfsGlobalWebContent CompanyName "Your company name
#This sets the name that is listed above the logon form
Set-AdfsWebTheme -TargetName default -Logo @{path=”c:Contosologo.png”}
#To set a logo
Set-AdfsWebTheme -TargetName default -Illustration @{path="c:background.png"}
#This sets the “illustration” – the image to the right of the sign-in form. Just change the path from “c:background.png” to the path to your image. Microsoft recommends the dimensions for the illustration to be 1420×1080 pixels @ 96 DPI with a file size of no greater than 200 KB
Set-AdfsGlobalWebContent -SignInPageDescriptionText "<P><B>Sign-in requires format yourdomainusername.</B></P>"
#This inserts the text right below the sign-in screen – it uses basic HTML for formatting. Simply type whatever text you want between the quotation marks.
And that’s it! Just a few simple changes and you have your custom ADFS 3.0 logon page! If you want other ways to change this, visit https://technet.microsoft.com/en-us/library/dn280950.aspx
Cheers!
Hi again!
Today I’m gonna explain a problem that I recently faced, I received a call from a customer, complaining about the SharePoint portal was down. Firstly, I tried to access to the portal and I was alarmed, I only see the error like: “Default Error in application server” nothing more. I observed that in the url stuck on https://appweb/_trust so I guess that something was happening with the ADFS.
I decided to check the Event Viewer log, and I found errors like the following:
Exception message: ID4220: The SAML Assertion is either not signed or the signature’s KeyIdentifier cannot be resolved to a SecurityToken. Ensure that the appropriate issuer tokens are present on the token resolver. To handle advanced token resolution requirements, extend Saml11TokenSerializer and override ReadToken.
at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
So, after viewing that, we decided to ask to customer IT deparment if they has renewed the ADFS certificate, and bang! was that the reason of the error. So all you need to solve this problem is to renew the ADFS certificate in the SharePoint Server. To do that, you have to execute the following PowerShell scripts:
$certPath = "C:certstokensigner.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")
New-SPTrustedRootAuthority -Name "Token Signing Certificate" -Certificate $cert
$sts = Get-SPTrustedIdentityTokenIssuer
$sts | Set-SPTrustedIdentityTokenIssuer -ImportTrustCertificate $cert
Albandrod's Memory 