November 2, 2021

SharePoint: Transport-level error has occurred when receiving results from the server

Problem

SharePoint 2016 (on-prem) farm had weird issues on few application and WFE servers. Namely, the servers couldn't connect to SQL Server, but ULS logs showed error:

Unknown SQL Exception 64 occurred. Additional error information from SQL Server is included below.  A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

When testing the connection with UDL file, the behavior was also strange, i.e., when testing the connection to server without defining any specific database, the test succeeded:


Also when defining a specific database, the test succeeded:



However, when attempting to list the databases by expanding the "Select the database on the server" dropdown, there was first "Unspesified error" error:


Followed by error "Microsoft Data Link
Login failed. Catalog information cannot be retrieved.":


Solution

Solution was (eventually) to fix the Jumbo Packet setting on the servers having the issue. Other servers had value 1514, while the problematic servers had value 9014 and changing value to 1514 made all the SharePoint servers immediately connect to SQL Server, and also the UDL DB listing started working.



September 29, 2021

Edge: Reverting to classic authentication dialog a.k.a disable Windows Hello for HTTP authentication

Problem

In recent Microsoft Edge browser versions 90+, the classic authentication dialog has been replaced by Windows Hello authentication prompt. It's all nice and secure, but at the moment at least, browser password vault extensions such as 1Password cannot fill in the credentials to that modern prompt. What it means is that you need to close the Windows Hello prompt, open password extension, copy username/password to notepad, refresh browser window, paste credentials from notepad to Windows Hello prompt. *yawn*

This is cumbersome in enterprise scenarios with various internal systems such as SharePoint that in specific scenarios require you to login with different credentials from the one you're currently logged into Windows.



Solution

For now the only solution is to disable the Windows Hello prompt in Edge. It will require using Group Policies wither on AD level, or on individual machine. The following steps are for individual machine, but if you're an AD admin, you can pick the essential pieces from the instructions and do the same on AD level policy.

  1. First download MS Edge policy file from https://aka.ms/EdgeEnterprise, from the drop-downs, select the version of your Edge, then press GET POLICY FILES


  2. Extract the .cab, and .zip ūüôĄ
  3. Navigate to .\MicrosoftEdgePolicyTemplates\windows\admx folder
  4. Copy msedge.admx to C:\Windows\PolicyDefinitions
  5. Navigate to .\MicrosoftEdgePolicyTemplates\windows\admx\en-US folder (NOTE! or the language of your Windows installation, if not en-US)
  6. Copy msedge.adml to C:\Windows\PolicyDefinitions\en-US
  7. Open Local Group Policy Editor, and navigate to Computer Configuration / Administrative Templates / Microsoft Edge / HTTP Authentication
  8. Edit Windows Hello For HTTP Auth Enabled setting, and set it to Disabled


  9. Click OK to confirm policy setting, and refresh page in Edge - no restart of any kind needed
  10. Applauds! Classic authentication prompt is back and you can also access the browser extension

September 20, 2021

Auth0: Invalid RSAES-OAEP padding

Problem

After configuring Auth0 with custom certificates via API, you get Access Denied error when attempting to login.

{ "error": "access_denied", "error_description": "Invalid RSAES-OAEP padding." }


Solution

Add an additional  decryptionKey to the connection's options with the following format.

options: {
  //... other options
  "decryptionKey" : {
        "key": "-----BEGIN PRIVATE KEY-----\n...",
        "cert": "-----BEGIN CERTIFICATE-----\n..."
    }
}

Keep in mind that options are replaced, not merged - so you'll need to send the whole options object to the PATCH call.

April 28, 2021

Azure B2C: Adding missing translations on Page Layouts

Problem

After starting to use Azure B2C custom Page Layout versions newer than 2.0.0, you will find translations are missing on many controls. Documentation is lacking behind, so it will take some trial and error to figure out some of the translation IDs. In the following pictures, you see missing translations marked with beautiful hand drawn red arrows.



Solution

As B2C _should_ already include these translations, the only workaround currently is to manually provide the missing strings in your Custom Policy. The following will work for urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.4 and urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.4.

So first of all, add LocalizedResourceReference elements in the ContentDefinition elements.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
<ContentDefinition Id="api.signuporsignin">
  <LoadUri>https://xyz.blob.core.windows.net/customui/ocean_blue/unified.html</LoadUri>
  <RecoveryUri>https://xyz.blob.core.windows.net/customui/ocean_blue/exception.html</RecoveryUri>
  <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.4</DataUri>
  <Metadata>
    <Item Key="DisplayName">Signin and Signup</Item>
  </Metadata>
  <LocalizedResourcesReferences MergeBehavior="Prepend">
    <LocalizedResourcesReference Language="fi" LocalizedResourcesReferenceId="api.signuporsignin.fi" />
  </LocalizedResourcesReferences>
</ContentDefinition>
<ContentDefinition Id="api.selfasserted">
  <LoadUri>https://xyz.blob.core.windows.net/customui/ocean_blue/selfAsserted.html</LoadUri>
  <RecoveryUri>https://xyz.blob.core.windows.net/customui/ocean_blue/exception.html</RecoveryUri>
  <DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.4</DataUri>
  <Metadata>
    <Item Key="DisplayName">Collect information from user page</Item>
  </Metadata>
  <LocalizedResourcesReferences MergeBehavior="Prepend">
    <LocalizedResourcesReference Language="fi" LocalizedResourcesReferenceId="api.localaccountpasswordreset.fi" />
  </LocalizedResourcesReferences>
</ContentDefinition>

Then the actual strings you will add in the Localization element.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
<LocalizedResources Id="api.signuporsignin.fi">
  <LocalizedStrings>
    <LocalizedString ElementType="ClaimType" ElementId="signInName" StringId="DisplayName">Sähköpostiosoite</LocalizedString>
    <LocalizedString ElementType="ClaimType" ElementId="password" StringId="DisplayName">Salasana</LocalizedString>
    <LocalizedString ElementType="UxElement" StringId="local_intro_generic">Kirjaudu sisään aiemmin luodulla tililläsi</LocalizedString>
  </LocalizedStrings>
</LocalizedResources>
<LocalizedResources Id="api.localaccountpasswordreset.fi">
  <LocalizedStrings>
    <LocalizedString ElementType="ClaimType" ElementId="email" StringId="DisplayName">Sähköpostiosoite</LocalizedString>
    <LocalizedString ElementType="ClaimType" ElementId="VerificationCode" StringId="DisplayName">Vahvistuskoodi</LocalizedString>
    <LocalizedString ElementType="ClaimType" ElementId="signInNames.emailAddress" StringId="DisplayName">Sähköpostiosoite</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="email">Sähköpostiosoite</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="ver_input">Vahvistuskoodi</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="verificationcode">Vahvistuskoodi</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="intro_msg">Syötä sähköpostiosoitteesi ja paina Lähetä vahvistuskoodi -painiketta.</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="but_send_code">Lähetä vahvistuskoodi</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="but_verify_code">Vahvista koodi</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="but_send_new_code">Lähetä uusi koodi</LocalizedString>
    <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationSSPRControl" StringId="success_send_code_msg">Vahvistuskoodi on lähetetty sähköpostiisi. Kopioi se alla olevaan syöteruutuun ja paina Vahvista koodi -painiketta.</LocalizedString>
  </LocalizedStrings>
</LocalizedResources>

Please note that this is not a comprehensive list of missing translations, so feel free to comment below if you happen to have a full tested list of translations that will work with the new Page Layouts.

March 23, 2021

Office Add-In: Empty group label

Problem

I needed to create Outlook Add-In Ribbon button without Group label, like the Insights Add-In does.



Solution

As the Group element requires Label, and the String of the Label requires DefaultValue to have some value, the workaround was to set the DefaultValue as one space character.



Ta-daa!



February 26, 2021

WebView2: How to hide scrollbars

Problem

When using the new Microsoft Edge WebView2 control, it often displays scroll bars and the control doesn't have any explicit property to hide the scroll bars.



Solution

You need to use custom Javascript at the NavigationCompleted event to hide the scrollbars. 

Simply add a new NavigationCompleted event handler for the WebView2 control and use the ExecuteScriptAsync method to run a Javascript that hides the scroll bars.

1
2
3
4
5
6
7
private void WebView2_NavigationCompleted(object sender, CoreWebView2NavigationCompletedEventArgs e)
{
    if (e.IsSuccess)
    {
        ((WebView2)sender).ExecuteScriptAsync("document.querySelector('body').style.overflow='hidden'");
    }
}

Note! Code above hides scrollbars AND disables scrolling. If you would like to hide scrollbars but retain scrolling (with touch for example), please use this code instead.

1
2
3
4
5
6
7
private void WebView2_NavigationCompleted(object sender, CoreWebView2NavigationCompletedEventArgs e)
{
    if (e.IsSuccess)
    {
        ((WebView2)sender).ExecuteScriptAsync("document.querySelector('body').style.overflow='scroll';var style=document.createElement('style');style.type='text/css';style.innerHTML='::-webkit-scrollbar{display:none}';document.getElementsByTagName('body')[0].appendChild(style)");
    }
}

January 27, 2021

Azure Managed Identity: Obtaining token gives error ‘invalid_client’

Problem

One of our Azure App Services suddenly started behaving badly and throwing HTTP 400 errors. From Application Insights we could see the error was coming from a call to LOCALHOST:PORT/MSI/token which is the location where access token is requested in case your code wants to access other Azure resources using Managed Identity (formerly MSI).

Troubleshooting

I went to Kudu PowerShell console of the given App Service and tried to manually get the access_token, but couldn’t.

Command for that is:
Invoke-WebRequest -Uri 'http://127.0.0.1:41332/MSI/token/?resource=https://management.azure.com/&api-version=2017-09-01' -Method GET -Headers @{Metadata="true";Secret="$env:MSI_SECRET"} -UseBasicParsing

Note! Port in the URL is different in your App Service, you can get it via @env:MSI_ENDPOINT.

All I got was HTTP 401 error with ‘invalid_client’ error code. Strange. In respective DEV App Service there was no errors and access_code was returned nicely.

By the way, details of the Uri and other parameters can be found here. Header is different if you’re using more recent api-version.

By the way, if you just run the Invoke-WebRequest, you will get error:

Win32 internal error "The handle is invalid" 0x6 occurred while reading the console output buffer. Contact Microsoft Customer Support Services.

No point in contacting MS Support, just run the following command and retry:

$ProgressPreference="SilentlyContinue"

Solution

Now, for the solution…good old IISRESET. Of course in Azure you restart the App Service in question. After restarting the App Service, you can re-run the Invoke-WebRequest, and access_token is returned correctly, and App Service works.