Coaching your guest users through the External Sharing Experience.
Here is a resource to which you can point those users you collaborate with using the guest user experiences on SharePoint Online. There are three possible experiences a user can encounter when being invited to SharePoint Online. We will deal with each of those in turn. Feel free to copy and paste this or provide the individual link for each invitation type, depending on which method of invitation you are using.Awareness of temporary adjustments in SharePoint Online
On March 24 th we shared in an announcement in the M365 message center (MC207439) details around temporary adjustments we are making to select capabilities in SharePoint Online and OneDrive. During these unprecedented times, we are taking steps to ensure that SharePoint Online and OneDrive services remain available and reliable for your users who depend on the service more than ever in remote work scenarios.Install SMTP Server and Telnet with PowerShell
Summary SharePoint and general app servers often use the SMTP Service to integrate e-mail into the systems functionality. Since Windows supports a well vetted SMTP Service, using the built-in application is often the best choice. With the said, when testing your app functionality with e-mail, Telnet is almost always needed and not installed by default. If you find yourself always rebuilding servers to test new features and functionality, you may install SMTP and Telnet manually each time. If this is the case, why not use PowerShell? What does the script do? If SMTP is not installed, the installation will proceed. Once completed, it will then detect if Telnet is already installed. If not, you will be asked if Telnet should be installed. If you run the script a server with SMTP or Telnet already installed, the app installation will be detected and skipped. I'm hoping this script will make your test builds quicker and more enjoyable in the future. The Script: # Check if SMTP is installed before installing it. $smtp = get-WindowsFeature "smtp-server" if(!$smtp.Installed){ write-host "SMTP is not installed, installing it..." -ForegroundColor red add-WindowsFeature $smtp } else{ write-host "SMTP is already installed!" -ForegroundColor Cyan sleep 2 } # Once SMTP is installed, prompt to install Telnet, if not installed. $telnet = get-WindowsFeature "telnet-client" if(!$telnet.Installed){ #Use a popup windows with a yes or no choice $shell = new-object -comobject "WScript.Shell" $choice = $shell.popup("Telnet is not installed, do you want to install it?",0,"Install Telnet",4+32) } else{ write-host "Telnet is already installed, done!" -ForegroundColor Green break } #If you get here telnet is not installed and the user choose Yes. if ($choice -eq "6"){ write-host "Installing Telnet..." -ForegroundColor Green Add-WindowsFeature $telnet write-host "Done!" -ForegroundColor Cyan } #If you got here telnet is not installed but the user chose No. if ($choice -eq "7" -and !$telnet.Installed){ write-host "Telnet is not installed and will not be installed!" -ForegroundColor Green break } The Output: Here is what you will see if SMTP and Telnet is not installed: Windows Popup asking if Telnet should be installed: Installing Telnet: Done: If SMTP and Telnet is already installed it be detected and skip the installation:Auto-Acceleration in SharePoint Online
Note: This is an earlier blog article that was previously hosted on the SharePoint Online Support blog on TechNet. It, and other articles, are being moved over to this site as part of an ongoing Global Blog effort by the SharePoint Online Support Organization. Information Technology is often tasked with two opposing goals: increase productivity by giving better and easier access to data; while at the same time, protecting that data from unauthorized access. This means that services such as SharePoint Online (and Office365 in general) must be able to correctly identify the user requesting the information, authenticate that user, then check that user's authorization to ensure that the user has the correct rights to the information they are requesting. Add in that these users might be authenticating against different providers and things become complicated.Is SMTP Auth Really Working?
Summary Now that SharePoint 2019 supports SMTP authentication you have the option to relay e-mail from SharePoint to any SMTP server that supports SMTP authentication. However, if you are using a port that falls back to anonymous, how do you if it's authenticating and not just falling back to anonymous Let's look at the traffic behind the covers To answer the question, you really need to inspect the traffic on the wire. Below I have provided 4 scenarios which customers may see when attempting to configure SMTP Auth with on-prem Exchange Servers. Scenario 1: Auth working with port 587 over Kerberos Here you will find a working configuration where SharePoint is set to use port 587 and SMTP Auth over Kerberos. This worked well without errors and the outcome was expected. Conversation on the wire: Exchange Receive Connector Permissions: SharePoint SMTP Auth Settings: Scenario 2: Auth working with port 25 over NTLM Here you will find a working configuration where SharePoint is set to use port 25 and SMTP Auth over NTLM. This worked well without errors and the outcome was expected. Conversation on the wire: SharePoint SMTP Auth Setting: Exchange Receive Connector Permissions: Take special note to this Exchange Receive Connector permission group settings. "Exchange Users" is enabled. SMTP Auth (as a user) requires the "Exchange Users" permission group, which is not on by default for the "Default Frontend SERVERNAME" receive connector, which listens on port 25. Scenario 3: Somewhat working with port 25 over NTLM Here you will find a "somewhat working" configuration where SharePoint is set to use port 25 over NTLM and SMTP Auth. However, the e-mail was sent, but anonymous was used instead of user authentication as expected. This failure occurred due to a configuration error, which is described below. Conversation on the wire: Errors Text: Response: 535 5.7.3 Authentication unsuccessful\r\n Response code: Authentication credentials invalid (535) Response parameter: 5.7.3 Authentication unsuccessful SharePoint SMTP Auth Setting: Exchange Receive Connector Permissions: Take special note to this Exchange Receive Connector permission group settings, as this is the default setting. SMTP Auth (as a user) requires the "Exchange Users" permission group, which is not on by default for the "Default Frontend EXCHANGE" receive connector, which listens on port 25. Scenario 4: Not working with port 587 over Kerberos Here you will find a "non-working" configuration where SharePoint is set to use port 587 over Kerberos and SMTP Auth. This resulted in failure after 3 attempts due to a configuration error, which is described below. Conversation on the wire: Errors Text: Response: 535 5.7.3 Unable to proxy authenticated session because either the backend does not support it or failed to resolve the user\r\n Response code: Authentication credentials invalid (535) Response parameter: 5.7.3 Unable to proxy authenticated session because either the backend does not support it or failed to resolve the user Response: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM\r\n Response code: Authentication required (530) Response parameter: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM SharePoint SMTP Auth Setting: Exchange Receive Connector Permissions: Why is this happening? There are several reasons why SharePoint SMTP authentication can fail, and I will list the reasons I'm aware of here. 1. Missing UPN: If the authenticating user does not have a UPN set, authentication will fail with error "5.7.3 Unable to proxy authenticated session because either the backend does not support it or failed to resolve the user". If you see this error, check the user configured in the SharePoint outing e-mail settings, to determine if the UPN is set. There are many ways to accomplish this, but I will show you the PowerShell method. Check with Get-ADUser: Get-ADUser spadmin DistinguishedName : CN=SpAdmin,OU=SpService,DC=contoso,DC=com Enabled : True GivenName : Name : SpAdmin ObjectClass : user ObjectGUID : 070d91df-5240-4569-8c1c-415bc9c20872 SamAccountName : SpAdmin SID : S-1-5-21-1111111111-111111111-111111111-1111 Surname : UserPrincipalName : Set the UPN for the SMTP Authenticating Account: Set-ADUser spadmin -UserPrincipalName spadmin@contoso.com Now Get it account one more time: Get-ADUser spadmin DistinguishedName : CN=SpAdmin,OU=SpService,DC=contoso,DC=com Enabled : True GivenName : Name : SpAdmin ObjectClass : user ObjectGUID : 070d91df-5240-4569-8c1c-415bc9c20872 SamAccountName : SpAdmin SID : S-1-5-21-1111111111-111111111-111111111-1111 Surname : UserPrincipalName : spadmin@contoso.com Note: Now the UPN is set 2. Incorrect Exchange Receive Connector permissions: As stated above if you are authenticating over SMTP as a user, the "Exchange Users" permission group must be enabled on the Exchange Receive Connector properties. If this permission is missing, SMTP authentication will fail with error, "Authentication credentials invalid (535)". 3. Kerberos requires SPNs: If the Exchange Server is missing the SMTPSVC Service Principal Name, authenticating over Kerberos may fail. Example of a missing SPN: setspn -l contoso\exchange Registered ServicePrincipalNames for CN=EXCHANGE,CN=Computers,DC=contoso,DC=com: TERMSRV/EXCHANGE TERMSRV/exchange.contoso.com WSMAN/exchange WSMAN/exchange.contoso.com RestrictedKrbHost/EXCHANGE HOST/EXCHANGE RestrictedKrbHost/exchange.contoso.com HOST/exchange.contoso.com Set the SPN with NETBIOS Name: setspn -s SMTPSVC/exchange contoso\EXCHANGE Checking domain DC=contoso,DC=com Registering ServicePrincipalNames for CN=SPWFE,CN=Computers,DC=contoso,DC=com: SMTPSVC/exchange Updated object Set the SPN with FQDN: setspn -s SMTPSVC/exchange.contoso.com contoso\EXCHANGE Checking domain DC=contoso,DC=com Registering ServicePrincipalNames for CN=EXCHANGE,CN=Computers,DC=contoso,DC=com: SMTPSVC/exchange.contoso.com Updated object Get the SPNs once again: setspn -l contoso\exchange Registered ServicePrincipalNames for CN=EXCHANGE,CN=Computers,DC=contoso,DC=com: SMTPSVC/exchange.contoso.com SMTPSVC/EXCHANGE TERMSRV/EXCHANGE TERMSRV/exchange.contoso.com WSMAN/exchange WSMAN/exchange.contoso.com RestrictedKrbHost/EXCHANGE HOST/EXCHANGE RestrictedKrbHost/exchange.contoso.com HOST/exchange.contoso.com Conclusion In summary don't set it and forget it! After configuring your SharePoint Server to use SMTP Authentication, check your network traffic to ensure its working as expected. You may need to work with your Active Directory (to set SPNs) and Exchange Team (to set connector properties) to ensure that E-mail is being sent using authentication. Also, if you came here because this blog matches the errors you are experiencing, I hope this helped you figure out the problem quickly. Thanks for reading!
