Tag: MIM Portal

Redirecting the root site to the MIM Portal

Problem

When you install the MIM Portal, the root site of your portal will display a rather glum page devoid of anything immediately useful. It looks like this:

image

This is not the portal you are looking for… The one you want is located at /IdentityManagement. Now, there are many ways to work around this. You may publish through some kind of load balancer and add the redirect there, you can install IIS URL Rewrite and fiddle around with the settings for a while, but the most elegant solution I have come across so far is to change the WelcomePage in SharePoint.

Solution

Source: http://konab.com/redirect-identitymanagement-site-spf-2013/.

 

Notes

  • I use an http link in the example as this is from a lab setup, but you should of course use SSL in production. HTTP to HTTPS redirect is another issue (for another post).
  • I have not tested this on SharePoint 2016, but it I see no reason why it shouldn’t work.

 

Action plan

  • Start by opening the SharePoint 2013 Management Shell.
  • Enter the following commands, replacing the web application name with the URL for your MIM Portal.
$webapp = Get-SPWeb http://portal.mim.local
$root = $webapp.RootFolder
$root.WelcomePage = "IdentityManagement/default.aspx"
$root.Update()
  • The change should take effect immediately.
Last edit: Wednesday, September 26, 2018

MIM: Sharepoint central administration returns 404

Problem

After an unscheduled reboot of some of my production MIM 2016, SharePoint central administration just returned a 404 error. As the reboot was caused by a massive network outage, pinpointing this specific error took some time.

 

Analysis

Rebooting the servers brought the MIM portal up again (after some time), but Sharepoint Central administration was still down. Rummaging around in the ULS log I came across this message, the first error message logged after trying to load the management site:

Failed to get document content data. System.TypeInitializationException: The type initializer for ‘Cobalt.MetricsBase`1’ threw an exception. —> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)

at System.Linq.Expressions.Expression.Parameter(Type type, String name)

at Cobalt.MetricsBase`1..cctor() –

— End of inner exception stack trace —

at Cobalt.MetricsBase`1..ctor()

at Microsoft.SharePoint.SPFileStreamHostBlobStore..ctor(SPFileStreamStore spFileStreamStore, Config config)

at Microsoft.SharePoint.SPFileStreamManager.CreateCobaltStreamContainer(SPFileStreamStore spfs, ILockBytes ilb, Boolean copyOnFirstWrite, Boolean disposeIlb)

at Microsoft.SharePoint.SPFileStreamManager.SetInputLockBytes(SPFileInfo& fileInfo, SqlSession session, PrefetchResult prefetchResult)

at Microsoft.SharePoint.CoordinatedStreamBuffer.SPCoordinatedStreamBufferFactory.CreateFromDocumentRowset(Guid databaseId, SqlSession session, SPFileStreamManager spfstm, Object[] metadataRow, SPRowset contentRowset, SPDocumentBindRequest& dbreq, SPDocumentBindResults& dbres)

at Microsoft.SharePoint.SPSqlClient.GetDocumentContentRow(Int32 rowOrd, Object ospFileStmMgr, SPDocumentBindRequest& dbreq, SPDocumentBindResults& dbres)

And this one followed:

Could not get DocumentContent row: 0x80131534.

Some searching brought up this discussion on Technet that contained the solution. It worked like a charm. As it is currently past 3am I have not made any attempt to discover why this happended, and why this solution works.

Update 2018-08-18: J. Qvarnström on the MIM FB Group suggested that the problem could be caused by .Net framework patches from June 2018. I checked, and there was indeed some .Net patches installed recently. In this particular case KB4099639 and KB4099635.

Update 2018-08-23: As suggested by M Kaufman on the MIM FB Group I tried to remove SCOM APM. That allowed me to remove the LoaderOptimization registry setting. SCOM APM has been installed since the server was created years ago according to our SCOM team, so something else must have triggered the problem. The .Net framework updates mentioned above are my primary suspects. That being said, SCOM APM is not supported on Sharepoint servers so it should be removed in any case.

Solution

As usual, do not perform these steps in production if you do not understand them. These steps should be performed on the MIM Portal servers.

Alternative 1: Disable SCOM APM

  • Aquire a copy of your current SCOM msi, usually called MOMAgent.msi and place it on the server.
  • Run the following command from an administrative command prompt:
msiexec.exe /fvomus "MOMagent.msi" NOAPM=1
  • Restart the server

Alternative 2: Change the .Net framework LoaderOptimization

If alternative 1 did not help, change the LoaderOptimization to 1. Be aware that this is a sledgehammer approach, but it is highly likely to get your system back up and running. Further investigation into the root cause is recommended.

  • Locate HKLM\SOFTWARE\Microsoft\.NETFramework
  • Add a new DWORD value called LoaderOptimization.
  • Set the value to 1. See MSDN for documentation.
  • Perform an iisreset.

image

Last edit: Thursday, August 23, 2018

MIM: The Portal cannot connect to the middle tier using the web service interface

Problem

After installing the MIM Service and Portal successfully, you are greeted by a portal that never loads and eventually displays a generic 503-error or a “Service not available notice”.

image

Analysis

This is a list of things I checked while trying to smoke out the badger causing this issue:

  • IIS bindings, even though I tested this prior to running the installer
  • The enormous setup log (verbose logging).
  • IISRESET.
  • Sharepoint alternate access mappings, also checked and found to be working prior to the installation.
  • Service status, both the FIM service and the Sharepoint services were running.
  • Restarted the server (have you tried turning it off and on again?).
  • FIM Event log, empty

And then I finally had the bright idea to check the application event log. It looked like the remnants of a great battle, only red and yellow messages in sight:

image

I dug in and found this one particularly interesting, Event 10 from Microsoft.ResourceManagement.PortalHealthSource:

The Portal cannot connect to the middle tier using the web service interface.  This failure prevents all portal scenarios from functioning correctly.


The cause may be due to a missing or invalid server url, a downed server, or an invalid server firewall configuration.


Ensure the portal configuration is present and points to the resource management service.

SNAGHTML2be3c711

I suddenly remembered that the load balancer was not yet configured and went to check the DNS records for the MIM urls. As I suspected, they were pointing to the load balancer, but the load balancer did not know where to redirect the traffic and thus did nothing.

Solution

For once, a simple solution without much of a risk factor:

  • Change the DNS record for the load balanced addresses, in this case the MIM Service server address to point directly to one of the portal servers.
  • Perform an IISRESET on the portal servers

I could of course fix the load balancer as well, but that requires a minion with access, and as the local time is 00:18 on a Saturday I will just add it to the list of things to fix later.

Last edit: Sunday, October 22, 2017