October 31, 2018

SharePoint: Most Incoming E-Mail Settings for a list are missing


When attempting to configure incoming e-mail settings of SharePoint 2013/2016 on-premises site, the list specific settings only allow enabling the incoming e-mail, and the e-mail address, but not the other options, such as what to do with the attachments.

Below picture is in Finnish, but you will see there are only these two settings, and nothing else.



You’ve probably gone through all settings related to incoming email, and mails are in fact arriving to the Drop folder of the SMTP Server on the SharePoint server and are probably even being processed as the emails disappear from the Drop folder.


You have custom SPEmailEventReceiver registered (via Site feature) on the site you’re on. In this scenario, the Incoming E-Mail Settings of a list will not allow you to configure further settings related to incoming emails.

It does make sense, as it is the custom event receiver handling the emails, so it would make little sense attempting to configure anything more on a single list as it would have no effect. It would of course be nice if the settings page would indicate why the settings are missing.

September 6, 2018

openssl config failed: error:02001003 when building SharePoint Framework (SPFx) web part


When building SharePoint Framework (SPFx) web part, you get errors related to openssl, such as

openssl config failed: error:02001003:system library:fopen:No such process


Also, if you run commands such as “npn -v", you will get same warnings. Depending where you run the commands from, you get the error in PowerShell command line, or classic CMD prompt, or both.

These errors/warnings do not, however, break anything in usual development scenarions, so SharePoint Workbench (local and hosted) work fine.


Error is due to missing environment variable pointing to OpenSSL config file. You can find the config file from OpenSSL installation folder under bin folder, e.g., "C:\OpenSSL-Win64\bin\openssl.cfg".

For PowerShell (=if you run the commands in Visual Studio Code Terminal), run:

$Env:OPENSSL_CONF = "C:\OpenSSL-Win64\bin\openssl.cfg"

For CMD prompt, run:

SET OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg


I prefer instead just installing 32 bit version of OpenSSL and not having to worry about these things.

August 16, 2018

Azure functions: The remote runtime "~1" is not compatible with your local runtime "beta".


When trying to deploy Azure Functions from Visual Studio Code, you get error “The remote runtime "~1" is not compatible with your local runtime "beta".”


As beta is not yet production ready, you may not want to update your Azure Functions in the portal to version 2, i.e., “beta”.


You probably created the Azure Function when you had version 2.0 of azure-functions-core-tools installed

npm i –g azure-functions-core-tools@core
when you should’ve installed the 1.0 version using
npm i -g azure-functions-core-tools

What you need to do is to go to VS Code workspace settings and change azureFunctions.projectRuntime from “beta” to “~1”. After that deployment works.


August 2, 2018

Cannot delete Azure Active Directory due to existing Enterprise Applications


After deleting all required objects from Azure AD, so you could delete it, the “Delete directory” validator still says “Delete all enterprise applications”, as there are custom Enterprise Applications preventing directory deletion.



Usually the reason is Microsoft Visual Studio Team Services Enterprise application. You can go to Properties, and flip “Enable for users to sign-in” to No, and it helps in some cases.


However, sometimes it is not enough, but you need to go and delete all Enterprise Applications via PowerShell (although many of them are internal Azure apps).

Command for logging in and deletion is:

Connect-AzureAD –TenantID <TENANT_ID>
#repeat the following line for EACH Enterprise Application, some will throw error, but ignore it
Remove-AzureADServicePrincipal –ObjectId <OBJECT_ID_OF_ENT_APP>

Then with your web browser, log out from the Azure portal, and log back in, and you should be able to delete the Azure AD using browser.

Do note that Get-AzureADServicePrincipal | Remove-AzureADServicePrincipal didn’t work for some reason, and I needed to do the removal one by one.

June 12, 2018

Suomi.fi e-identification using Auth0

As it states on the Suomi.fi e-Identification service page, “Suomi.fi e-Identification enables the citizens of Finland and the European Union to be recognized in a safe way by using various identification media such as bank-id and mobile certificates.”

As suomi.fi authentication offers user authentication service across SAML 2.0 compliant interface, and Auth0.com supports SAMLP Identity Providers, configuring the two sohuldn’t be too much of a problem.

Configuring Auth0

These steps will assist you in configuring Auth0 towards suomi.fi test environment. Steps for production environment are mostly the same, but there are few additional steps related to certificates.

  1. Register for Auth0 tenant (https://auth0.com), Trial will work just fine for this test scenario
  2. Add suomi.fi as SAMLP Identity Provider at Connections –> Enterprise –> SAMLP Identity Provider

  3. Type in Connection name. It can be anything, but I suggest to keep it short and without special characters. I call it suomi-fi-test
  4. For Sign In URL, type in the POST signin URL endpoint of suomi.fi test environment:
  5. For X509 Signing Certificate upload the suomi.fi (which is IdP in this case) public key, so basically suomi.fi will sign the outgoing messages with their private key, and here you define the corresponding public key to verify the message signature.

    You can get the certificate from suomi.fi metadata URL at https://testi.apro.tunnistus.fi/static/metadata/idp-metadata.xml. Paste X509Certificate string into *.txt file, add certificate markers -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- (required by Auth0), rename file to *.cer, and upload to Auth0.

  6. Sign Out URL, add the Single Log Out URL of suomi.fi:
  7. User Id Attribute you can decide what user data returned by suomi.fi is considered as the user identificator in Auth0, I’m using urn:oid:, which is the National Identification Number of the user. You can find the other fields at https://esuomi.fi/palveluntarjoajille/tunnistus/tekninen-aineisto/tunnistetusta-kayttajasta-valitettavat-attribuutit/.
  8. Enable Sign Request, and download the certificate, you will use that later.
  9. Sign Request Algorith, set to RSA-SHA256.
  10. Sign Request Digest Algorithm, set to SHA256.
  11. Protocol Binding, set to HTTP-POST.
  12. Request Template you can leave as-is.
  13. On the Mappings tab (at the top), I map user name details so user list in Auth0 is more convenient to manage:
       "name": "urn:oid:2.16.840.1.113730.3.1.241",
       "given_name": "urn:oid:",
       "family_name": "urn:oid:"

Creating SAML Metadata

Final step is to contact suomi.fi and do some paperwork, most impotantly from a technical perspective is to send them description of your service, i.e., the SAML Metadata.

In SAML Metadata you define things like

  • authentication methods you want to support (bank, mobile, etc.)
  • user details you would like to get back from suomi.fi after authentication (e.g., National Id of the user, name, address)

You will also need to include the public Auth0 signing certificate you downloaded earlier in step 8.

It is recommended to start from this sample SAML Metadata, and modify it accordingly.

EntityID, SingleLogoutService, and AssertionConsumerService you can get from Auth0 Setup Instructions page by clicking on the Pen button after creating the Enterprise Connection.


NOTE! Before sending the metadata to suomi.fi, you should validate it at https://www.samltool.com/validate_xml.php by pasting the metadata into the XML field, selecting Metadata for XSD. This will save you some time and effort as the metadata won’t bounce back at least due to trivial syntax errors.


After metadata has been configured in suomi.fi environment, you’re all set and can test the authentication by pressing the PLAY button next to the Enterprise Connection.

Browser should redirect you to the authentication method selection screen in suomi.fi, and eventually after successful authentication back in Auth0 together with the user details (claims) you defined in SAML Metadata.

April 26, 2018

SharePoint: Setting person field default values in “Column default value settings”


SharePoint doesn’t allow setting person field default values in “Column default value settings” of a list, in fact, it doesn’t even show the person type fields in the “Column default value settings” screen.


Using browser, you cannot do it, but modifying /yourlist/forms/client_LocationBasedDefaults.html using SharePoint Designer or programmatically makes it possible. Just put in the full user identity claim, below sample is from SharePoint Online.

<DefaultValue FieldName="MyPersonFieldName">i:0#.f|membership|firstname.lastname@mydomain.onmicrosoft.com</DefaultValue>

SharePoint: Multiple default values using “Column default value settings”


SharePoint doesn’t allow selecting multiple default values in “Column default value settings” of a list, even though the column in question is choice and allowing multiselect.


Using browser, you cannot do it, but modifying /yourlist/forms/client_LocationBasedDefaults.html using SharePoint Designer or programmatically makes it possible. Just use format ;#CHOICE1;#CHOICE2;#, e.g.,
<DefaultValue FieldName="MyMultiChoiceFieldName">;#Valintatalo;#Citymarket;#</DefaultValue>