Renewed Microsoft Trainer Certification for 2021-2022

I have renewed my Microsoft Certified Trainer certification for 2021-2022. The big requirement was to teach a MOC class during the calendar year and get the MTM surveys in the system to be able to renew. Most Microsoft employees renew internally, but I am currently NOT working for Microsoft. I was able to get the classes taught so that I was able to renew for the new year.

Microsoft Certified Trainer 2021-2022

LDLNET LLC IT Consulting Business is currently CLOSED.

I am still available for music performance through my company but the IT Side of the business has been closed as I am on a full time project and cannot devote any outside time to IT consulting. Thank everyone for supporting me over the years. My blog will still remain current so please check here often for the latest updates for Exchange, M365, Security, Compliance, and Windows!

STEPS TO DECOMMISSIONING YOUR EXCHANGE 2010 ON-PREMISES ENVIRONMENT

This was a great article released by the Exchange Team Blog today, and as I have been dealing with MANY customers still having Exchange 2010, I wanted to have this available for quick review! It has great links and steps to consider when finally getting off Exchange 2010.

Best practices when decommissioning Exchange 2010

As many of you know from the previous post regarding Exchange On-Premises Best Practices for Migrations from 2010 to 2016 the end of support for Exchange 2010 is quickly approaching. We’ve created this post to cover the best practices for decommissioning an Exchange 2010 environment after the migration has completed.

Uninstalling Exchange 2010 is as easy as running Setup and selecting to remove the server roles, but there are prerequisites to removing the roles and legacy items left over, which should be removed.

This post is intended to provide best practices to plan for and complete the Exchange 2010 decommission. Please note that since there are many different types of deployments and configurations it is difficult to cover all scenarios, but many of the common steps are included here. Please plan the decommission process carefully.

As a general statement, here are some things that we want to caution against:

  • Do not reuse Exchange 2010 server names (until they have been fully decommissioned).
  • Do not reuse Exchange 2010 server IP addresses (until they have been fully decommissioned).

This post assumes that your organization is maintaining some Exchange presence on-premises, whether Exchange 2013 or 2016 (we do not mention Exchange 2019 in this post because it cannot coexist with Exchange 2010). If your organization has moved all mailboxes to Office 365 and is in a Hybrid environment, we are assuming you will maintain an Exchange footprint per Scenario 2 in How and when to decommission your on-premises Exchange servers in a hybrid deployment.

Preparing for Soft Shut Down

Once you’ve completed the migration from Exchange 2010 to, let’s say, Exchange 2016, you should prepare the 2010 environment prior to decommissioning the servers. The following steps to consider are separated into server roles when preparing for a soft shut down and preparing for the removal of server roles.

Client Access (CAS) Role

Check Server FQDNs

Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for client connectivity and ensure they are routing to the 2016 environment. These are all the names that are published for Outlook Anywhere, AutoDiscover, and all Exchange Virtual Directories.

Tip: Verify that all clients such as ActiveSync, Outlook, EWS, OWA, OAB, POP3/IMAP, and Autodiscover are no longer connecting to the legacy Exchange servers. Verification of this can be done by reviewing the servers’ IIS Logs with Log Parser Studio (LPS). LPS is a GUI for Log Parser 2.2 and it greatly reduces the complexity of parsing logs. LPS can parse large sets of logs concurrently (we have tested with total log sizes of >60GB). Please refer to the following blog post with tips and information on using LPS.

Check SCPs

Make sure that the Service Connection Point (SCP) is moved to Exchange 2016 as discussed in the Exchange On-Premises Best Practices for Migrations from 2010 to 2016 post under the Configure Autodiscover SCP for Internal Clients section.

If present, ensure that if the AutoDiscoverServiceInternalURI routes to an Exchange 2016 endpoint. You can also remove this value by setting the AutoDiscoverServiceInternalURI to $Null.

Hub Transport Role

Follow the items below to review all mail flow connectors. We will not be removing connectors themselves, simply auditing to ensure that the server is ready to be decommissioned.

Review the Send Connectors

Review the send connectors and ensure that the legacy servers have been removed and Exchange 2016 servers have been added. Most organizations only permit outbound network traffic on port 25 to a small number of IP addresses, so you may also need to review the outbound network configuration.

Review the Receive Connectors

Review the receive connectors on legacy servers and ensure they are recreated on your Exchange 2016 servers (e.g. SMTP relay; anonymous relay; partner, etc.). Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for inbound mail routing and ensure they are terminating against the Exchange 2016 environment. If your legacy Exchange servers have any custom, third-party, or foreign connectors installed (for example, with fax services), ensure that they can be reinstalled on 2016 Exchange servers.

Tip: Check the SMTP logs to see if any outside systems are still sending SMTP traffic to the servers via hard coded names or IP addresses. To enable logging, review Configure Protocol Logging. Also, ensure we have “time coverage” for any apps relaying weekly/monthly emails that may not be caught in a small sample size of SMTP Protocol logs. There is a great script available here that can help find any applications that may be relaying off your legacy environment.

In general, the decommissioning process is a great time to audit your mail flow configuration to ensure that all the connectors are properly configured and secured. Maybe it’s time to get rid of any of those Anonymous Relay connectors that may be in use in your environment. Or, if Hybrid, possibly relay against Office 365.

Transport Rules

Exchange 2010 base transport rules are held in a different AD container than Exchange 2013 and newer rules. When installing Exchange 2016 in your environment it will import those Exchange 2010 based rules. However, any changes to Exchange 2010 rules after a later version of Exchange is installed must also be applied to your Exchange 2016 rules. This is further explained here under section Coexistence with Exchange 2010.

Run the following command to get all your Exchange Transport Rules. Must be run on Exchange 2016 to see all rules.

Compare the rules with RuleVersion of 14.X.X.X to those with 15.1.X.X. If any Exchange 2010 rules don’t exist on Exchange 2016, they must be created. Also review all settings of each Exchange 2010 rule and replicate them to Exchange 2016.  

Mailbox Role

Identity and move all Exchange 2010 mailboxes to Exchange 2016

Decommissioning Exchange 2010 cannot be initiated until all mailboxes have been moved to Exchange 2016. As an example, we cannot decommission Exchange 2010 Hub Transport servers completely until all of the mailboxes are moved off the legacy platform, this is due to how Delivery Groups are handled.

We encourage using the newest Exchange platform to process any move requests. If moving to Exchange 2016, move all mailboxes via Exchange 2016. Also, ensure that once all moves are completed, and that all associated Move Requests are removed as well. Any lingering move requests or mailboxes will prevent uninstallation of Exchange 2010.

To move all user mailboxes, run the following command to identify the mailboxes, and then plan to move them to the new platform.

Tip: Ensure that Archives are included with “Get-Mailbox -Archive” if you used Exchange Archives in 2010. Also, do not forget about your Discovery Search mailboxes – these can be found with: Get-Mailbox -Filter { RecipientTypeDetails -eq “DiscoveryMailbox”}. These will need to be moved (if they haven’t yet already), to Exchange 2016 as well.

Identify and Move Arbitration Mailboxes to Exchange 2016

It’s necessary to move the arbitration mailboxes from Exchange 2010 to 2016 for many Exchange Services to work properly, including the Exchange Admin Center (EAC). This is typically executed when Exchange 2016 is first installed, however, if that was missed, we will ensure that is handled now. The process to move is defined at: Move the Exchange 2010 system mailbox to Exchange 2013+. To verify which system mailboxes are located on 2010, use PowerShell on your Exchange 2010 server with the following example:

Note: If any mailboxes are present, move them to an Exchange 2016 database.

OAB Generation

Installing first Exchange Server 2013+ into Exchange 2010 organization creates a new OAB. It also marks the new OAB as default. The Exchange 2010 OAB is not used by Exchange 2013+ servers so moving the OAB is not necessary. Move the OAB to another Exchange 2010 server, if you are removing an Exchange 2010 server that’s currently hosting the OAB, and there are other Exchange 2010 servers in the org. If you are removing the last Exchange 2010 server in the org, remove the OAB.

Migrate All Legacy Public Folders

Verify that all the public folders have been migrated to Exchange OnlineOffice 365 Groups, or Exchange Modern public folders.

Mail Enabled Public Folders (MEPF) consideration

If the following is true:

  • Exchange Server 2010 public folders are migrated to Exchange Online
  • Exchange Server 2013/2016 was introduced on-premises
  • MEPF’s are still used on-premises to send emails to Exchange Online

In that case, you may need to run the SetMailPublicFolderExternalAddress.ps1 script to ensure Exchange 2013+ servers can continue sending emails to Exchange Online MEPFs.

Decommission the Database Availability Group (DAG)

Assuming best practices were followed for the Exchange 2010 environment, we will have a DAG for HA/DR capabilities. Now that all mailboxes have been removed from the 2010 environment, we are ready to tear down this DAG to move forward with decommissioning Exchange 2010.

Remove Database Availability Group (DAG) Copies

First, we start with the copies. For every mailbox database copy in the environment hosted on Exchange 2010, we will need to remove the Mailbox Database Copy. This can be done via the UI, or via PowerShell:

NOTE: Removing the copy will not remove the actual .edb database file from the Server.

Remove All Nodes from Database Availability Group(s) (DAG)

For each Exchange 2010 server in the environment, we will need to remove the individual server from the DAG. This is evicting the server from the cluster. This can be done via the UI, or through PowerShell.

Remove DAGs

Lastly, once the Database copies are removed, and the servers are evicted from the cluster, the last thing is to finally remove the DAG from the environment. This can be done with the following PowerShell command:

Tip: If you have an even-membered DAG, and leveraged a File Share Witness, don’t forget to decommission the file share witness that was used for the Exchange 2010 DAG.

Unified Messaging Role

Configuration steps are required to move Exchange 2010 UM to Exchange 2016 servers. The following link can be used to guide through removal of UM from Exchange 2010. If moving to a third-party UM solution, remove the UM components to allow un-installation of the UM role.

Edge Role

If you have an Edge server, you will need to install Exchange 2016 Edge and recreate the Edge Subscription on the E2016 server. This is further documented here.

Other

As mentioned in the beginning of the document, due to so many different types of deployments and configurations, it’s difficult to cover all scenarios however it’s recommended to check any other possible scenarios that apply to your environment.

Third Party Applications

Make a list of applications that may be using Exchange 2010 (e.g. EWS, mail transport, database-aware) and make sure to configure these applications to start using Exchange 2016 infrastructure.

Shut-Down Exchange 2010 Servers

Test shutting down the Exchange servers for a few days to a few weeks to see if there are any issues. You are auditing for any applications that are trying to connect to the Exchange 2010 servers or trying to send email through the Exchange 2010 servers.  Enabling protocol logging on the Hub Transport roles prior to shutting down the servers is an option. That way if any mail is processing through these servers, upon restart, the logging will begin immediately.  If applications or servers are trying to connect you can remediate those or power on the Exchange 2010 servers until remediation can happen.

Tip: Check Active Directory DNS Zone settings to see if DNS Scavenging is enabled.  If this is enabled, the DNS record could become stale during the shutdown time frame and cause DNS issues for the Exchange 2010 server.

Preparing for Removal of Server Roles

As you begin the process of removing servers, you should go through the list below and ensure you have everything tested and ready to go.

CAS

Remove CAS Arrays

Remove Any Exchange 2010 Client Access Arrays from Active Directory and DNS. Refer to the following document to remove the Client Access Array object with Shell using the following example:

Be sure to also remove any references in DNS to the CAS Array Name.

Remove Unused 2010 ASAs

If you followed either the Best practices for Migrations blog or the Coexistence with Kerberos blog, we recommend that any old alternate service accounts (ASAs) used for E2010 be removed. If you are using a different namespace than Exchange 2016, please verify old SPNs are also removed.

Remove Exchange 2010 OAB

Use the following command to remove Exchange 2010 OAB:

Remove Mailbox Databases

Now that all mailboxes are migrated from the Exchange 2010 platform, and the DAG is properly removed, we will want to decommission any leftover databases from the Exchange 2010 environment. To remove all Exchange 2010 databases, review the output of the following, and remove individually:

And then remove the database with:

NOTE: If there are any mailboxes currently residing on the database, we will not let you remove the database, it will fail with the following error:

e2010decom1.jpg
Remove Legacy Public Folders

If you chose not to migrate public folders, refer to the following document to remove public folders with either EMC or Shell using the following example:

Remove Legacy Public Folder Databases

Refer to the following document to remove the public folder databases with PowerShell using the following example:

Tip: Remember the .edb files linger after the above is done. Feel free to delete, backup, or do with these as you please.

Uninstall Exchange 2010

It’s recommended to uninstall in the following order: CAS, Hub, UM (if any), then Mailbox.  

Starting the Uninstall Process

When you begin the uninstall process, close EMC, EMS, and any additional programs that could delay uninstall process (i.e. programs using .NET assemblies; antivirus and backup agents are examples). You can either run Exchange 2010 Setup.exe or navigate to Control Panel to modify or remove Exchange 2010 (either server roles or the entire installation). Specific steps are discussed in Modify or Remove Exchange 2010.

Tip: Exchange will protect itself! If you properly uninstall via Add/Remove Programs, it will ensure that it is ready to be uninstalled via Readiness Checks! If all the above prep work is completed before hand, it should uninstall just fine.

After Uninstall of Exchange 2010

After uninstalling Exchange there will be some general “housekeeping” tasks. These may vary depending on the steps taken during your upgrade and depending on your organization’s operational requirements.

Examples include:

  • Removing the legacy Exchange computer accounts from AD (including the DAG’s Cluster Name Object and any Kerberos ASA object).
  • Removing the legacy Exchange name records from DNS (including the DAG’s Cluster Name Object and any Kerberos ASA object).
  • Ensure the folder on the DAG file share witness (FSW) servers were successfully removed, possibly removing Exchange’s rights on the server if it isn’t serving double duty for Exchange 2016.
  • Removing old load balanced IP addresses and routes from your network load balancer.
  • Remove old firewall rules that open ports to Exchange 2010 environment.
  • Removing and disposing of the legacy Exchange environment’s physical equipment.
  • Deleting of the legacy Exchange environment’s virtual machines.

Conclusion

With the uninstall of the last server, hopefully Exchange 2010 treated your organization well. The Exchange product team takes great pride of the success of the platform and hope that you see the same success with Exchange 2016 (or Exchange Online!). Messaging sure has come a long way since it was released way back in 2009.

REFERENCES
Exchange Team Blog article on Decommissioning Exchange 2010 On-Premises

CHECK FOR CONTINUED UPDATES!
THANKS FOR STOPPING BY!

Why go to Exchange 2019 from 2016 and 2013?

I get asked this a lot in my travels, “What’s the difference with Exchange 2019 and why should we go to it other than the fact that it is the latest version released. I wanted to post my findings from articles that I found to help explain some of the improvements and differences with running Exchange 2019.

Exchange Server 2019 brings a new set of technologies, features, and services to Exchange Server, the messaging platform that provides email, scheduling, and tools for custom collaboration and messaging service applications.

What is NOT in Exchange 2019…

There are some things that have been discontinued in Exchange 2019 which make the decision to go to it important for some companies.

Architecture

FeatureComments and mitigation
Unified Messaging (UM)Unified Messaging has been removed from Exchange 2019. We recommend that Exchange 2019 organizations transition to Skype for Business Cloud Voice Mail.

This is a big deal for some companies as they rely on Unified Messaging to handle their Voice Messaging. There are some articles available to view to assist in transitioning from UM to the new voicemail features with O365. I will post them as I find them in this blog. Keep tuned in for updates!

Here are some other deprecated features:

Client Access server roleThe Client Access server role has been replaced by Client Access services that run on the Mailbox server role. The Mailbox server role now performs all functionality that was previously included with the Client Access server role. For more information about the new Mailbox server role, see Exchange Server architecture.
MAPI/CDO libraryThe MAPI/CDO library has been replaced by Exchange Web Services (EWS), Exchange ActiveSync (EAS), and Representational State Transfer (REST)* APIs. If an application uses the MAPI/CDO library, it needs to move to EWS, EAS, or the REST APIs to communicate with Exchange 2019.

De-emphasized Features

The following features are being de-emphasized in Exchange 2019 and may not be included in future versions of Exchange.

  • Third-party replication APIs
  • RPC over HTTP
  • Database availability group (DAG) support for failover cluster administrative access points (You can have IPLess DAGs now)

What’s new when upgrading to Exchange 2019?

Security

  • Windows Server Core support: Running Exchange on a Windows deployment with less surface area means less attack surface area and fewer components to service.
  • Block external access to Exchange admin center (EAC) and the Exchange Management Shell: You can use Client Access Rules to only allow administration of Exchange from the internal network instead of using complex network and firewall rules.
  • TLS 1.2 is the only version that’s enabled by default: Exchange Server 2019 includes important changes to improve the security of client and server connections. The default configuration for encryption will enable TLS 1.2 only and disable support for older algorithms (namely, DES, 3DES, RC2, RC4 and MD5). It will also configure elliptic curve key exchange algorithms with priority over non-elliptic curve algorithms. In Exchange Server 2016 and later, all cryptography settings are inherited from the configuration specified in the operating system.

Performance

  • Improved search infrastructure: The completely rebuilt search infrastructure for cloud scale and reliability in Exchange Online is now available in Exchange 2019. This new search infrastructure allows for indexing of bigger files, simpler management, and better search performance.
  • Faster, more reliable failovers: The changes to the search architecture result in significantly faster and more reliable failover over between servers.
  • Metacache database: Improvements at the core of Exchange’s database engine enable better overall performance and take advantage of the latest storage hardware, including larger disks and SSDs.
  • Modern hardware support: Exchange now supports up to 256 GB of memory and 48 CPU cores.
  • Dynamic database cache: The information store process employs dynamic memory cache allocation optimizing memory usage to active database usage.

Clients

  • Calendar – Do Not Forward: This is similar to Information Rights Management (IRM) for calendar items without the IRM deployment requirements. Attendees can’t forward the invitation to other people, and only the organizer can invite additional attendees.
  • Calendar – Better Out of Office: Additional options when you won’t be in the office. Key options include: add an event to your calendar that shows you as Away/Out of Office, and a quick option to cancel/decline meetings that will happen while you’re away.
  • Calendar – Remove-CalendarEvents cmdlet: Enables administrators to cancel meetings that were organized by a user that has left the company. Previously, conference rooms or meeting attendees would have these defunct meetings permanently on their calendars.
  • Assign delegate permission via PowerShell: Updates to the Add-FolderPermissions cmdlet so administrators can assign delegate permissions.
  • Email address internationalization (EAI): Email addresses that contain non-English characters can now be routed and delivered natively.

Exchange 2019 architecture

Today, CPU horsepower is significantly less expensive and is no longer a constraining factor. With that constraint lifted, the primary design goal for Exchange 2019 is for simplicity of scale, hardware utilization, and failure isolation. With Exchange 2019, we reduced the number of server roles to two: the Mailbox and Edge Transport server roles.

Unified Messaging (UM) has been removed from Exchange 2019. Other than that, the Mailbox server in Exchange 2019 includes all of the server components from the Exchange 2013 Mailbox and Client Access server roles:

  • Client Access services provide authentication, limited redirection, and proxy services. Client Access services don’t do any data rendering and offer all the usual client access protocols: HTTP, POP and IMAP, and SMTP.
  • Mailbox services include all the traditional server components found in the Exchange 2013 Mailbox server role except Unified Messaging: the backend client access protocols, Transport service, and Mailbox databases. The Mailbox server handles all activity for the active mailboxes on that server.

The Edge Transport role is typically deployed in your perimeter network, outside your internal Active Directory forest, and is designed to minimize the attack surface of your Exchange deployment. By handling all Internet-facing mail flow, it also adds additional layers of message protection and security against viruses and spam, and can apply mail flow rules (also known as transport rules) to control message flow.

For more information about the Exchange 2019 architecture, see Exchange architecture.

Along with the new Mailbox role, Exchange 2019 now allows you to proxy traffic from Exchange 2013 Client Access servers to Exchange 2019 mailboxes. This new flexibility gives you more control in how you move to Exchange 2019 without having to worry about deploying enough front-end capacity to service new Exchange 2019 servers.

MAPI over HTTP

MAPI over HTTP is now the default protocol that Outlook uses to communicate with Exchange. MAPI over HTTP improves the reliability and stability of the Outlook and Exchange connections by moving the transport layer to the industry-standard HTTP model. This allows a higher level of visibility of transport errors and enhanced recoverability. Additional functionality includes support for an explicit pause-and-resume function, which enables supported clients to change networks or resume from hibernation while maintaining the same server context.

Note: MAPI over HTTP isn’t enabled in organizations where the following conditions are both true:

  • You’re installing Exchange 2019 in an organization that already has Exchange 2013 servers installed.
  • MAPI over HTTP wasn’t enabled in Exchange 2013.

While MAPI over HTTP is now the default communication protocol between Outlook and Exchange, clients that don’t support it will fall back to Outlook Anywhere (RPC over HTTP).

Outlook on the Web
(formerly known as Outlook Web App)

Outlook Web App is now known as Outlook on the web, which continues to let users access their Exchange mailbox from almost any web browser.

NOTE: Supported Web browsers for Outlook on the web in Exchange 2019 are Microsoft Edge, Internet Explorer 11, and the most recent versions of Mozilla Firefox, Google Chrome, and Apple Safari.

The former Outlook Web App user interface has been updated and optimized for tablets and smart phones, in addition to desktop and laptop computers. New Exchange 2019 features include:

  • Platform-specific experiences for phones for both iOS and Android.
  • Premium Android experience using Chrome on devices running Android version 4.2 or later.
  • Email improvements, including a new single-line view of the Inbox with an optimized reading pane, archiving, emojis, and the ability to undo mailbox actions like deleting a message or moving a message.
  • Contact linking the ability for users to add contacts from their LinkedIn accounts.
  • Calendar has an updated look and new features, including email reminders for Calendar events, ability to propose a new time in meeting invitations, improved search, and birthday calendars.
  • Search suggestions and refiners for an improved search experience that helps users find the information they want, faster. Search suggestions try to anticipate what the user’s looking for and returns results that might be what the user is looking for. Search refiners will help a user more easily find the information they’re looking for by providing contextually-aware filters. Filters might include date ranges, related senders, and so on.
  • New themes Thirteen new themes with graphic designs.
  • Options for individual mailboxes have been overhauled.
  • Link preview which enables users to paste a link into messages, and Outlook on the web automatically generates a rich preview to give recipients a peek into the contents of the destination. This works with video links as well.
  • Inline video player saves the user time by keeping them in the context of their conversations. An inline preview of a video automatically appears after inserting a video URL.
  • Pins and Flags which allow users to keep essential emails at the top of their inbox (Pins) and mark others for follow-up (Flags). Pins are now folder specific, great for anyone who uses folders to organize their email. Quickly find and manage flagged items with inbox filters or the new Task module, accessible from the app launcher.
  • Performance improvements in a number of areas across Outlook on the web, including creating calendar events, composing, loading messages in the reading pane, popouts, search, startup, and switching folders.
  • New Outlook on the web action pane that allows you to quickly click those actions you most commonly use such as New, Reply all, and Delete. A few new actions have been added as well including Archive, Sweep, and Undo.

Document collaboration
(On-Premises and in O365)

Exchange 2019, along with SharePoint Server 2019 and SharePoint Online, enables Outlook on the web users to link to and share documents that are stored in OneDrive for Business in an on-premises SharePoint server instead of attaching files to messages. Users in an on-premises environment can collaborate on files in the same manner that’s used in Office 365.

When an Exchange 2019 user receives a Word, Excel, or PowerPoint file in an email attachment, and the file is stored in OneDrive for Business or on-premises SharePoint, the user will now have the option of viewing and editing that file in Outlook on the web alongside the message. To do this, you’ll need a separate computer in your on-premises organization that’s running Office Online Server.

Exchange 2019 also brings the following improvements to document collaboration:

  • Saving files to OneDrive for Business.
  • Uploading a file to OneDrive for Business.
  • Most Recently Used lists populated with both local and online files.

Office 365 hybrid and the HCW

The Hybrid Configuration Wizard (HCW) that was included with Exchange 2013 is moving to become a cloud-based application. When you choose to configure a hybrid deployment in Exchange 2019, you’ll be prompted to download and install the wizard as a small app. The wizard will function the same in previous versions of Exchange, with a few new benefits:

  • The wizard can be updated quickly to support changes in the Office 365 service.
  • The wizard can be updated to account for issues detected when customers try to configure a hybrid deployment.
  • Improved troubleshooting and diagnostics to help you resolve issues that you run into when running the wizard.
  • The same wizard will be used by everyone configuring a hybrid deployment who’s running Exchange 2013 or later.

In addition to Hybrid Configuration Wizard improvements, multi-forest hybrid deployments are being simplified with Azure Active Directory Connect (AADConnect). AADConnect introduces management agents that will make it significantly easier to synchronize multiple on-premises Active Directory forests with a single Office 365 tenant.

Exchange ActiveSync clients will be seamlessly redirected to Office 365 when a user’s mailbox is moved to Exchange Online. To support this, ActiveSync clients need to support HTTP 451 redirect. When a client is redirected, the profile on the device is updated with the URL of the Exchange Online service. This means the client will no longer attempt to contact the on-premises Exchange server when trying to find the mailbox.

Secure Messaging, Policy, and Compliance

Data loss prevention

To comply with business standards and industry regulations, organizations need to protect sensitive information and prevent its inadvertent disclosure. Examples of sensitive information that you might want to prevent from leaking outside your organization include credit card numbers, social security numbers, health records, or other personally identifiable information (PII). With a DLP policy and mail flow rules (also known as transport rules) in Exchange 2019, you can now identify, monitor, and protect 80 different types of sensitive information with new conditions and actions:

  • With the new condition Any attachment has these properties, including any of these words, a mail flow rule can match messages where the specified property of the attached Office document contains specified words. This condition makes it easy to integrate your Exchange mail flow rules and DLP policies with SharePoint, Windows Server 2012 R2 File Classification Infrastructure (FCI), or a third-party classification system.
  • With the new action Notify the recipient with a message, a mail flow rule can send a notification to the recipient with the text you specify. For example, you can inform the recipient that the message was rejected by a mail flow rule, or that it was marked as spam and will be delivered to their Junk Email folder.
  • The action Generate incident report and send it to has been updated to enable the notification of multiple recipients by allowing a group address to be configured as the recipient.

In-place Archiving, retention, and eDiscovery

Exchange 2019 includes the following improvements to In-Place Archiving, retention, and eDiscovery to help your organization meet its compliance needs:

  • Public folder support for In-Place eDiscovery and In-Place Hold: Exchange 2019 integrates public folders into the In-Place eDiscovery and Hold workflow. You can use In-Place eDiscovery to search public folders in your organization, and you can put an In-Place Hold on public folders. And similar to placing a mailbox on hold, you can place a query-based and a time-based hold on public folders. Currently, you can only search and place a hold on all public folders. In later releases, you’ll be able to choose specific public folders to search and place on hold. For more information, see Search and place a hold on public folders using In-Place eDiscovery.
  • Compliance Search: Compliance Search is a new eDiscovery search tool in Exchange 2019 with new and improved scaling and performance capabilities. You can use it to search very large numbers of mailboxes in a single search. In fact, there’s no limit on the number of mailboxes that can be included in a single search, so you can search all mailboxes in your organization at once. There’s also no limit on the number of searches that can run at the same time. For In-Place eDiscovery in Exchange 2019, the limits are the same as in Exchange 2013: you can search up to 10,000 mailboxes in a single search and your organization can run a maximum of two In-Place eDiscovery searches at the same time.

Indexing and Search Architecture

In Exchange 2019, the search architecture has been redesigned. It is now based on the same engine as the modern search engines are and is directly on the mailbox in Exchange 2019. There is no content index database attached to the mailbox database as in previous versions of Exchange Server. Previously, search was a synchronous operation that was not very fault-tolerant. The new architecture is asynchronous and decentralized. It distributes the work across multiple servers and keeps retrying if any servers are too busy. This means that we can return results more reliability, and faster.

Another advantage of the new architecture is that search scalability is improved. The number of mailboxes you can search at once using the console has increased from 5k to 10k for both mailboxes and archive mailboxes, allowing you to search a total of 20k mailboxes at the same time.

ENJOY YOUR UPGRADE!
LEARN, DO, LIVE!

REFERENCES:
What is new in Exchange Server
What is discontinued in Exchange Server
Exchange Server TLS Guidance
Exchange Architecture

Welcome to my IT Blog…

This blog is going to be a dedicated repository linked to pages, posts, documentation, links, and information that I find during my troubleshooting processes within the IT world. Some posts will contain code snippets that you can use with your own work if needed. Feel free to comment and get this thing rolling!

I now have contributors! Please welcome their input as valued colleagues in the IT Industry! Be on the lookout for their blog posts and please comment!

LDLNET LLC – Your source for Professional IT Services

May 2021 Exchange Server Security Updates

Microsoft is currently releasing MONTHLY updates as a precaution ever since the zero day threat that occurred in March. I think it is imperative to make sure you keep you Exchange servers up-to-date as Security is a major component in the Modern Workspace. Please keep tuned in to this blog for updates and thank you to the Exchange Team for putting out these timely updates!!

Microsoft has released security updates for vulnerabilities found in:

  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

These updates are available for the following specific builds of Exchange Server:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 and CU20
  • Exchange Server 2019 CU8 and CU9

The May 2021 security updates for Exchange Server address vulnerabilities responsibly reported by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.

These vulnerabilities affect on-premises Microsoft Exchange Server, including servers used by customers in Exchange Hybrid mode. Exchange Online customers are already protected and do not need to take any action.

More details about specific CVEs can be found in Security Update Guide (filter on Exchange Server under Product Family).

Known issues in May 2021 security updates

During the release of April 2021 SUs, we received some reports of issues after installation. The following issues reported for April 2021 SUs also apply to May SUs and have the following workarounds:

  • Administrator/Service accounts ending in ‘$’ cannot use the Exchange Management Shell or access ECP. The only workaround at this time is to rename Admin accounts or use accounts with no ‘$’ at the end of the name.
  • Some cross-forest Free/Busy relationships based on Availability address space can stop working (depending on how authentication was configured) with the error: “The remote server returned an error: (400) Bad Request.” Please see this KB article for how to work around this problem.
  • After application of the Exchange Server April or May security updates, cmdlets executed against the Exchange Management Console using an invoked runspace might fail with the following error message: The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode. Please see this KB article for more information.

New security functionality in May 2021 security updates

We are making one additional change in May SU to make it easier for Exchange administrators and cybersecurity teams to quickly inventory the update state of the Exchange Servers on their networks. Specifically, we have added a protocol reply header containing Exchange Server version information to http responses that can be used by defenders to validate security update status of servers on your networks.

Update installation

Two update paths are available:

thumbnail image 1 of blog post titled 
 Released: May 2021 Exchange Server Security Updates

Inventory your Exchange Servers

Use the Exchange Server Health Checker script (use the latest release), to inventory your servers. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs and SUs).

Update to the latest Cumulative Update

Go to https://aka.ms/ExchangeUpdateWizard and choose your currently running CU and your target CU. Then click the “Tell me the steps” button, to get directions for your environment.

If you encounter errors during or after installation of Exchange Server updates

If you encounter errors during installation, see the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

FAQs

My organization is in Hybrid mode with Exchange Online. Do I need to do anything?
While Exchange Online customers are already protected, the May 2021 security updates do need to be applied to your on-premises Exchange Server, even if it is used only for management purposes. You do not need to re-run the Hybrid Configuration Wizard (HCW) after applying updates.

Do the May 2021 security updates contain the April 2021 security updates for Exchange Server?
Yes, our security updates are cumulative. Customers who installed the April 2021 security updates for supported CUs can install the May 2021 security updates and be protected against the vulnerabilities that were disclosed during those months.

Do I need to install the updates on ‘Exchange Management Tools only’ workstations?
Servers or workstations running only Microsoft Exchange Management Tools (no Exchange services) do not need to apply these updates.

The Exchange Team


REFERENCES:
Released: May 2021 Exchange Server Security Updates – Microsoft Tech Community

Why Exchange Server Updates Matter

THANK YOU EXCHANGE TEAM FOR THIS ARTICLE! In the field there has always been a difficulty when it comes to advising a client to maintain their Exchange Server Updates. The common theme is if it’s not broke, don’t fix it! That is why a lot of companies were still on Exchange 2010 SP3 in 2019!!! Please read the following and consider the consequences of NOT updating your Exchange Servers in the three month rotation. There are a lot of links in the document as well to point you in the correct direction! Thanks again for your patronage!

It is very important to keep updating your Exchange Servers to a supported Cumulative Update (CU). Simply put, your on-premises environments should always be ready to take an emergency security update (this applies to Exchange, Windows, and other Microsoft products you use on-premises). One thing we learned during the March 2021 release of Exchange Server security updates is that many of our customers were not ready to install security updates because they were not on supported cumulative update versions. With the threat landscape rapidly evolving, the importance of keeping your environment current should not be underestimated.

Please keep your Exchange Servers up to date. We want to continue helping you keep your environment secure, and this means your Exchange servers need to be up to date. This is a continuous process.

Once your Exchange servers are running a supported CU, ensure that the latest available Security Update (SU) is also installed. This will help address any vulnerabilities found since the release of the supported CU. To find recently released Exchange Server SUs, go to the Security Update Guide (filter on Exchange Server under Product Family). Exchange Server security updates are cumulative (an update released in April will also contain security fixes released in March, for example). We also announce all major updates on our blog.

We have prepared a set of questions and answers that cover what we hear most often about Exchange updates. If you are running into a different set of challenges keeping your environment up to date, please let us know in comments below!

Q&A

I updated my Exchange Servers a few months ago! How come they are ‘not supported’ today?

For versions of Exchange that are within mainstream support (see product lifecycle), Microsoft supports (releases relevant security fixes for) the two latest CUs. Sometimes the latest two CUs are referred to as “N and N-1”. As a current example, if the latest released CU is CU9 (‘N’), and the server version is Exchange Server 2019, then Microsoft at this time supports two Exchange Server 2019 CUs, N and N-1 (CU9 and CU8). When CU10 is released, the “supported CU window” will slide toward the newly released CU10 (and what used to be the N-1 supported CU, CU8, will become unsupported).

thumbnail image 1 of blog post titled 
 Why Exchange Server updates matter

Why does Microsoft release updates so often?

It is good that updates are released when issues are found. Microsoft (and other software vendors) release updates only when they are needed. CUs typically contain resolutions to feature problems that were reported to us by our customers (and can contain security updates from previous SUs) and are released quarterly. SUs are released only when actual security issues are found and fixed, and are typically released on a ‘patch Tuesday’. Let’s take an example of how a typical release flow for two CUs and two SUs we might release would look like:

  • On a particular month (let’s say March), we might release CU4; CU4 is cumulative and will include fixes and updates from before.
  • A month later we release CU4 SU1, a security update for CU4.
  • In May we then release CU4 SU2, an additional security update for CU4. CU4 SU2 will include updates released in CU4 SU1 also.
  • In June we release CU5, which will contain all updates released up to that point.
thumbnail image 2 of blog post titled 
 Why Exchange Server updates matter

My Exchange Servers are working as expected, so why update them?

While we appreciate the ‘don’t fix what is not broken’ thinking, the reality is that keeping Exchange Server current allows you to ensure that it will keep working without major interruptions to functionality. Investing some time into Exchange Server maintenance (on your planned schedule) will give you a long-term benefit of well running system, with code as protected from vulnerabilities as you can get it.

Updating Exchange Server seems complicated; what exactly do I do?

Think of updating Exchange server in several stages:

  1. Take inventory: use the Exchange Server Health Checker script on GitHub to see if you are behind on your on-premises Exchange Server updates.
  2. Install updates: visit https://aka.ms/ExchangeUpdateWizard and choose your currently running CU and your target CU. Then click the “Tell me the steps” button, to get a list of steps to follow.
  3. Troubleshoot (if needed): follow the ExchangeUpdateWizard instructions and best practices for installation of updates carefully, including when to use an elevated command prompt. If you encounter errors during or after installation, see Repair failed installations of Exchange Cumulative and Security updates.

Why did Microsoft suddenly start releasing Exchange Server security updates?

Releasing security updates for Exchange Server is not new. Microsoft has been releasing Exchange Server updates on ‘patch Tuesday’ for years (when issues are found). Keeping up with these updates is a best practice.

How can I update Exchange Server when (insert 3rd party application name here) does not support either of the latest supported Exchange Server CUs?

Work with your 3rd party vendor to bring their software current in a timely manner. Consider that your Exchange environment contains a lot of valuable company directory and messaging information. Your priority should be to keep your environment as secure as possible.

How can we stay current when we are a 24×7 business and have no time to take our servers down for maintenance?

Many customers require Exchange Server to work 24×7. In fact, our update process is designed for these high-demand businesses. You should use Database Availability Groups (DAGs) and put servers that you are updating in Maintenance mode to enable a graceful and non-disruptive update process for your users. See Performing maintenance on DAG members for more information.

If we are in Hybrid mode and don’t actively use our on-premises Exchange Server, do we still need to stay current?

Even if you are only using Exchange Server on-premises to manage Exchange-related objects, you need to keep the server current. Note that the Hybrid Configuration Wizard (HCW) does not need to be re-run after updates are installed.

I looked at recent security update releases and the Common Vulnerabilities and Exposures (CVE) severity was not very high; so why update?

Microsoft recommends that you apply all available security updates because it can be difficult to understand how even lower severity vulnerabilities disclosed in one month might interact with vulnerabilities disclosed and fixed a month later. An attack may trigger only specific low-impact functionality on a remote target machine and nothing else, causing the scoring for the CVE to be quite low one month. For example, in the following month an important issue with that functionality could be discovered, but it might be only triggered locally and require significant user interaction. That on its own might also not be scored highly. But if your software is behind in updates, these two issues could combine into an attack chain, thereby scoring at critical levels.

We find it difficult to update because Active Directory (AD) schema extensions and Exchange installations require different teams to take action.

In cases where different teams need to perform separate actions to prepare for installation of Exchange Cumulative Updates (as those might require AD schema extension) – we recommend you request schema changes when we release new CUs that require them. Even if you do not need to update to the very latest CU (because last two CUs are supported for Exchange versions that are still within support lifetime) – the fact that Active Directory schema will be up to date means that if you do find that you need to install the latest CU, AD schema will already be updated. We release CUs quarterly and not all of them will require AD schema updates. You can track this here for Exchange 2016 and here for Exchange 2019.

The Exchange Team

REFERENCES:
Why Exchange Server updates matter – Microsoft Tech Community

Enabling Modern Authentication for Outlook – How Hard Can It Be?

This type of authentication has been around since about 2017 timeframe with OAuth v1 and now has updated with OAuth2. I worked with doing some OAuth calls when I was in EXO CSS at Microsoft. I wanted to pass this Exchange Team Blog article along since it has come out with updates recently.

Since we announced in 2019 that we would be retiring Basic Authentication for legacy protocols we have been encouraging our customers to switch to Modern Authentication. Modern Authentication, based on OAuth2, has a lot of advantages and benefits as we have covered before, and we’ve yet to meet a customer who doesn’t think it is a good thing. But the ‘getting there’ part might be the hard part, and that’s what this blog post is about.

This post is specifically about enabling Modern Authentication for Outlook for Windows. This is the client most widely used by many of our customers, and the client that huge numbers of people spend their day in. Any change that might impact those users is never to be taken lightly.

As Admin, you know you need to get those users switched from Basic to Modern Auth, and you know all it takes is one PowerShell command. You took a look at our docs, found the article called Enable or disable Modern Authentication for Outlook in Exchange Online | Microsoft Docs and saw that all you need to do is read the article (which it says will take just 2 minutes) and then run:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

That sounds easy enough. So why didn’t you do it already?

Is it because it all sounds too easy? Or because there is a fear of the unknown? Or spiders? (We’re all scared of spiders, it’s ok.)

We asked some experts at Microsoft who have been through this with some of our biggest customers for their advice. And here it comes!

Expert advice and things to know

“Once Exchange Online Modern Authentication is enabled for Outlook for Windows, wait a few minutes.”

That was the first response we got. It was certainly encouraging, but wasn’t exactly a lot of information we realized, so we dug in some more, and here’s what we found.

One thing you need to remember that enabling Modern Authentication for Exchange Online using the Set-OrganizationConfig parameter only impacts Outlook for Windows. Outlook on the Web, Exchange ActiveSync, Outlook Mobile or for Mac etc., will continue to authenticate as they do today and will not be impacted by this change.

Once Modern Authentication is turned on in Exchange Online, a Modern Authentication supported version of Outlook for Windows will start using Modern Authentication after a restart of Outlook. Users will get a browser-based pop up asking for UPN and Password or if SSO is setup and they are already logged in to some other services, it should be seamless.

If the login domain is setup as Federated, the user will be redirected to login to the identity provider (ADFS, Ping, Okta, etc.) that was set up. If the domain is managed by Azure or set up for Pass Through Authentication, the user won’t be redirected but will authenticate with Azure directly or with Azure on behalf of your Active Directory Domain Service respectively.

Take a look at your Multi-Factor Authentication (MFA)/Conditional Access (CA) settings. If MFA has been enabled for the user and/or Conditional Access requiring MFA has been setup for the user account for Exchange Online (or other workloads that have a dependency on Exchange Online), then the user/computer will be evaluated against the Conditional Access Policy.

  • Here is an example of a CA policy with Condition of Client App “Mobile apps and desktop clients”. This will impact Outlook for Windows with Modern Authentication whereas “Other Clients” would impact Outlook for Windows using Basic Authentication, for example.
  • thumbnail image 1 of blog post titled 
 Enabling Modern Auth for Outlook – How Hard Can It Be? 
Next is Access Control Grant in CA requiring MFA. If Outlook for Windows was using Basic Authentication, this would not apply since MFA depends on Modern Authentication. But once you enable Modern Authentication, users in the scope of this CA policy would be required to use MFA to access Exchange Online.
thumbnail image 2 of blog post titled 
 Enabling Modern Auth for Outlook – How Hard Can It Be?

The Modern Authentication setting for Exchange Online is tenant-wide. It’s not possible to enable it per-user, group or any such structure. For this reason, we recommend turning this on during a maintenance period, testing, and if necessary, rolling back by changing the setting back to False. A restart of Outlook is required to switch from Basic to Modern Auth and vice versa if roll back is required.

It may take 30 minutes or longer for the change to be replicated to all servers in Exchange Online so don’t panic if your clients don’t immediately switch, it’s a very big infrastructure.

Be aware of other apps that authenticate with Exchange Online using Modern Authentication like Skype for Business. Our recommendation is to enable Modern Authentication for both Exchange and Skype for Business.

Here is something rare, but we have seen it… After you enable Modern Authentication in an Office 365 tenant, Outlook for Windows cannot connect to a mailbox if the user’s primary Windows account is a Microsoft 365 account that does not match the account they use to log in to the mailbox. The mailbox shows “Disconnected” in the status bar.

This is due to a known issue in Office which creates a miscommunication between Office and Windows that causes Windows to provide the default credential instead of the appropriate account credential that is required to access the mailbox.

This issue most commonly occurs if more than one mailbox is added to the Outlook profile, and at least one of these mailboxes uses a login account that is not the same as the user’s Windows login.

The most effective solution to this issue is to re-create your Outlook profile. The fix was shipped in the following builds:

  • For Monthly Channel Office 365 subscribers, the fix to prevent this issue from occurring is available in builds 16.0.11901.20216 and later.
  • For Semi-Annual Customers, the fix is included in builds 16.0.11328.20392 (Version 1907) and later.

You can find more info on this issue here and here.

That’s a list of issues we got from the experts. Many customers have made the switch with little or no impact.

How do you know Outlook for Windows is now using Modern Auth?

When using Basic Auth, the Outlook Connection Status “Authn” column shows “Clear*”

thumbnail image 3 of blog post titled 
 Enabling Modern Auth for Outlook – How Hard Can It Be?

Once you switch to Modern Auth, the Connection Status in Outlook showing Modern Authentication “Authn” column shows “Bearer*”

thumbnail image 4 of blog post titled 
 Enabling Modern Auth for Outlook – How Hard Can It Be?

And that’s it!

The biggest thing to check prior to making the change are your CA/MFA settings, just to make sure nothing will stop access from happening and making sure your users know there will be a change that might require them to re-authenticate.

Now you know what to expect, there is no need to be afraid of enabling Modern Auth. (Spiders, on the other hand… are still terrifying, but that’s not something we can do much about.)

REFERENCES:
Enabling Modern Auth for Outlook – How Hard Can It Be? – Microsoft Tech Community
Enable or disable modern authentication for Outlook in Exchange Online | Microsoft Docs

Released: April 2021 Exchange Server Security Updates

Microsoft has released security updates for vulnerabilities found in:

  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

These updates are available for the following specific builds of Exchange Server:

IMPORTANT: If manually installing security updates, you must install .msp from elevated command prompt (see Known Issues in update KB article).

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU19 and CU20
  • Exchange Server 2019 CU8 and CU9

Vulnerabilities addressed in the April 2021 security updates were responsibly reported to Microsoft by a security partner. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.

These vulnerabilities affect Microsoft Exchange Server. Exchange Online customers are already protected and do not need to take any action.

For additional information, please see the Microsoft Security Response Center (MSRC) blog. More details about specific CVEs can be found in Security Update Guide (filter on Exchange Server under Product Family).

Two update paths are:

Update Path

Inventory your Exchange Servers

Use the Exchange Server Health Checker script, which can be downloaded from GitHub (use the latest release), to inventory your servers. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs and SUs).

Update to the latest Cumulative Update

Go to https://aka.ms/ExchangeUpdateWizard and choose your currently running CU and your target CU. Then click the “Tell me the steps” button, to get directions for your environment.

If you encounter errors during or after installation of Exchange Server updates

Make sure to follow the ExchangeUpdateWizard instructions and best practices for installation of updates carefully, including when to install using elevated command prompt. If you encounter errors during or after installation, see Repair failed installations of Exchange Cumulative and Security updates.

FAQs

My organization is in Hybrid mode with Exchange Online. Do I need to do anything?
While Exchange Online customers are already protected, the April 2021 security updates do need to be applied to your on-premises Exchange Server, even if it is used only for management purposes. You do not need to re-run the Hybrid Configuration Wizard (HCW) after applying updates.

Do the April 2021 security updates contain the March 2021 security updates for Exchange Server?
Yes, our security updates are cumulative. Customers who installed the March 2021 security updates for supported CUs can install the April 2021 security updates and be protected against the vulnerabilities that were disclosed during both months. If you are installing an update manually, do not double-click on the .msp file, but instead run the install from an elevated CMD prompt.

Is Microsoft planning to release April 2021 security updates for older (unsupported) versions of Exchange CUs?
No, we have no plans to release the April 2021 security updates for older or unsupported CUs. In March, we took unprecedented steps and released SUs for unsupported CUs because there were active exploits in the wild. You should update your Exchange Servers to supported CUs and then install the SUs. There are 47 unsupported CUs for the affected versions of Exchange Server, and it is not sustainable to release updates for all of them. We strongly recommend that you keep your environments current.

Can we use March 2021 mitigation scripts (like EOMT) as a temporary solution?
The vulnerabilities fixed in the April 2021 updates are different from those we fixed before. Therefore, running March 2021 security tools and scripts will not mitigate the vulnerabilities fixed in April 2021. You should update your servers as soon as possible.

Do I need to install the updates on ‘Exchange Management Tools only’ workstations?
Servers or workstations running only Microsoft Exchange Management Tools (no Exchange services) do not need to apply these updates.

Why are there security updates two months in a row?
Microsoft regularly releases Exchange Server security updates on ‘patch Tuesday’. We are always looking for ways to make Exchange Server more secure. You should expect us to continue releasing updates for Exchange Server in the future. The best way to be prepared for new updates is to keep your environment current.

Is there no update for Exchange Server 2010?
No, Exchange 2010 is not affected by the vulnerabilities fixed in the April 2021 security updates.

Is there a specific order of installation for the April 2021 security updates?
We recommend that you update all on-premises Exchange Servers with the April 2021 security updates using your usual update process.

REFERENCES:
Released: April 2021 Exchange Server Security Updates – Microsoft Tech Community
April 2021 Update Tuesday packages now available – Microsoft Security Response Center

Renewing your GoDaddy SSL certificate from CRT/CER to PFX so it can be installed on IIS

I always have issues getting my certificate renewed using OpenSSL and the certificates that GoDaddy lets you download. I chose IIS and I chose Exchange Server in the GoDaddy download section of the site to get the CRT file. The issue I always have is converting it to PFX so that I can install it with a private key on my IIS Server. This is also relevant if you are using Azure to host your certificates as Microsoft requires PFX certificates in that realm.

So finally after I get it working today, I wanted to write this blog post to make sure I at least have a sure method to get the certificate converted with the private key. NOTE that this is for a certificate that has NOT expired.

First, download your certificate from GoDaddy to the server you have OpenSSL installed on.

Download the Certificate

Next, extract the cert to your directory and note the path. You will use the path in your OpenSSL cmdlet.

You may be seeing other files in there. Well the issue was that I couldn’t generate the proper private key and the PEM file given by GoDaddy did not work in the conversion. So, here is what I had to do on the Web Server to export the proper private key:

In the MMC Certificate Utility, export the current certificate with the private key:

  • Choose to Export the Key and Extended Properties
  • Choose a password and set the encryption to SHA256
  • Name the File and Export it to the directory you’re working from

Next, run the following cmd in OpenSSL to extract the private key from the exported certificate. Enter the password you created during the export when prompted:

Next, use that key file along with the CRT file to create the new PFX. Enter the password again when prompted:

You should now have the proper NEW PFX file to import into IIS or Azure or where ever you need to the certificate installed with the private key! DON’T forget your password!

THANKS FOR READING!! KEEP LEARNING AND REMEBER TO DOCUMENT SO YOU DON’T HAVE TO REMEMBER ALL THE TIME!

REFERENCES:
Extracting Certificate and Private Key Files from a .pfx File – IAM – UW-IT Wiki (washington.edu)
Convert a certificate to PFX (GoDaddy, unable to load private key) – UseIT | Roman Levchenko (rlevchenko.com)

Exchange Server Quarterly Updates – March 2021

I like to post the Exchange Server CU Updates when they are released by the Exchange Team. It is important to keep up to date with the Exchange Updates especially after the Zero Day threat that came out the early part of March. Thank you for your continued reading and patronage!

Summary

Today we are announcing the availability of quarterly servicing cumulative updates (CUs) for Exchange Server 2016 and Exchange Server 2019. These CUs include fixes for customer reported issues as well as all previously released security updates. Although we mentioned in a previous announcement that this release would be the final cumulative update for Exchange 2016, we do expect to release one more CU for Exchange 2016 next quarter which will includes all fixes made for customer reported and accepted issues received before the end of mainstream support.

A full list of fixes is contained in the KB article for each CU, but we wanted to highlight that these latest CUs contain the fixes that were previously released as Exchange Server Security Updates on March 2, 2021. This means you don’t have to install the March 2021 Security Updates after installing the March 2021 CUs.

The KB articles that describe the fixes in each release and product downloads are as follows:

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. These updates contain schema and directory changes and so require you prepare Active Directory (AD) and all domains. You can find more information on that process here.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to Unrestricted on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use these resolution steps to adjust the settings.

Additionally, a reminder that if you plan to install any Cumulative Update using the unattended option with either PowerShell or Command Prompt, make sure you specify either the full path to the setup.exe file or use a “.” in front of the command if you are running it directly from directory containing the update. If you do not the Exchange Server Setup program may indicate that it completed successfully when it did not. Read more here.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, and those using Exchange Online Archiving with their on-premises Exchange deployment are required to deploy the currently supported CU for the product version in use.

For the latest information on the Exchange Server and product announcements please see What’s New in Exchange Server and Exchange Server Release Notes.

Note: Documentation may not be fully available at the time this post is published.

REFERENCES:

Released: March 2021 Quarterly Exchange Updates – Microsoft Tech Community

Keep your Federation Trust up-to-date

This article came out in February and I have been behind on my blog updates due to my current project, but I feel this post is important and am going to relay the message that I received here for your review. Thanks again for your support of this blog and its continued longevity.


Microsoft periodically refreshes certificates in Office 365 as part of our effort to maintain a highly available and secure environment. From Jan 23rd, 2021, we are making a certificate change on our Microsoft Federation Gateway every six weeks that could affect some customers as detailed in this knowledge base article. Please note that longer term, this “six week” rhythm to renew the certificate will be further shortened to daily renewals which will further enhance security of the environment. The good news is you can easily avoid any disruption.

Who is affected?

This certificate change can affect any customer that is using the Microsoft Federation Gateway (MFG). If you are in a hybrid configuration that relies on a Federation Trust established with MFG in the Exchange on-premises organization or if you are sharing free/busy information between two different on-premises organizations using the Microsoft Federation Gateway as a trust broker, you need to take action.

When will the change occur?

The change is scheduled to occur every six weeks to begin with, with this frequency further increasing. You must take action to avoid any disruptions.

What type of issues will you face if no action is taken?

If you don’t take action, you won’t be able to use services that rely on the Microsoft Federation Gateway. For example:

  • A cloud user might not be able to see free/busy information for an on-premises user and vice versa.
  • MailTips might not work in a Hybrid configuration.
  • Cross-premises free/busy might stop working between organizations that have organization relationships in place.

Additionally, if you run the Test-FederationTrust cmdlet, you might receive an error message that indicates that the Delegation token has validation issues. For example, you receive an error message that resembles the following:

Id : TokenValidation
Type : Error
Message : Failed to validate delegation token.

And, you might receive one of the following error messages in the Exchange Web Services (EWS) responses:

An error occurred when processing the security tokens in the message
Autodiscover failed for email address User@contoso.com with error System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message

What action should you take?

You can use the following command on your Exchange Server to create a scheduled task to run the update process daily. This is how we recommend you keep your Federation Trust constantly updated. This will prevent you from being negatively affected by future metadata changes.

If you prefer to not use a scheduled task, you can manually run the command at any time to refresh the metadata. This is not recommended as the frequency to refresh certificate will increase from 6 week period to daily, and manually updating this would be quite cumbersome.

Please note that we have seen some situations where this command should be run twice to ensure it is successful.


REFERENCES:
Keep your Federation Trust up-to-date – Microsoft Tech Community

Support Announcement: March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server

There was a zero day threat in Exchange recently and I wanted to put out this update that I received from the Microsoft team so that it would be available to my followers and readers. I will try to keep this updated as much as I can as I am not updating my blog as much with my current projects taking up most of my time. Thanks to everyone and keep in touch!

Summary

To help customers more quickly protect their environments in light of the March 2021 Exchange Server Security Updates, Microsoft is producing an additional series of security updates (SUs) that can be applied to some older (and unsupported) Cumulative Updates (CUs). The availability of these updates does not mean that you don’t have to keep your environment current. This is intended only as a temporary measure to help you protect vulnerable machines right now. You still need to update to the latest supported CU and then apply the applicable SUs. If you are already mid-update to a later CU, you should continue with that update.

With these new updates, you will have a new path you can take:

What are these updates? 

  • These update packages contain only fixes for March 2021 CVEs (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065); no other product updates or security fixes are included. Installing these updates does not mean an unsupported CU is now supported.
  • Updates are available only through the Microsoft Download Center (not on Microsoft Update).
  • We are producing updates only for some older CUs for Exchange 2016 and 2019.
  • If you are running a version of Exchange not covered by these updates, consider either rolling forward to a CU package that has an applicable SU, or rolling forward to a supported CU (preferred option). In case you need to go forward with CUs, please see: best practices for installation of Exchange updates (applies to all versions of Exchange).

About installation of these updates

  • These updates must be installed from an elevated command prompt:
    1.        Download the update but do not run it immediately.
    2.        Select Start, and type CMD.
    3.        In the results, right-click Command Prompt, and then select Run as administrator.
    4.        If the User Account Control dialog box appears, choose Yes, and then select Continue.
    5.        Type the full path of the .msp file, and then press Enter.
  • Installing the SUs mentioned here and then installing a later CU will make the server vulnerable to exploits again until the CU you install contains the March 2021 security fixes (Exchange 2016 CU 20 and Exchange 2019 CU 9 – and newer – will include March 2021 security updates).
  • Installing updates requires a reboot (even if not prompted). The server will not be protected until after the reboot.
  • After installing one of these updates, you might see older Exchange security updates for your older CU available for download from Microsoft Update. Install the older security update from Microsoft Update and your servers will stay protected (for 4 CVEs mentioned before).
  • If you run into issues after installation, please see https://aka.ms/exupdatefaq first. You can also uninstall these updates (using Add/Remove Programs) if needed.

These additional updates are about to be to available in KB5000871.

IMPORTANT: You must install .msp updates from elevated command prompt (see Known Issues in the update KB article)

If you install these additional updates, please ensure that you continue to bring your Exchange environment to supported state as soon as possible. Our original announcement Released: March 2021 Exchange Server Security Updates contains information and resources that can help you plan your updates, troubleshoot problems, and help you with mitigations, investigation, and remediation of the vulnerabilities.

Additional news about investigations

To aid defenders in investigating these attacks where Microsoft security products and tooling may not be deployed, we are releasing a feed of observed indicators of compromise (IOCs). The feed of malware hashes and known malicious file paths observed in related attacks is available in both JSON and CSV formats at the below GitHub links. This information is being shared as TLP:WHITE.

Please keep checking the below blog post for any related updates.

The Exchange Team

REFERENCES:
March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server – Microsoft Tech Community

Issue with opening AIP/MIP Protected PDF Documents in Microsoft Edge

Over the past few weeks, I have been doing my own deep dive study into MIP/AIP. I was looking at the following article:

Which PDF readers are supported for protected PDFs?

This article said that the later versions of the Edge Browser should natively be able to open and view MIP UL Protected PDF documents:


So I proceeded to do a Edge browser check on my Windows 10 test machine:

Approved Version 86 of Edge

Great! I should be able to protect a PDF file as Confidential, and then be able to open it in Edge with no other software required.

This was NOT the case.

I protected the PDF:

File set to Confidential Label

I waited a few minutes and then tried to open the file. I received the following error:

I received a permissions error and not the standard blocking error

Another issue with this error is that I did not receive the standard issued AIP Protection error that you should get like you would when opening a protected document without the proper plug-in with Adobe Reader:

The error in Edge said to check ownership permissions, which I did:

Amy C. Carlson is my test user for this scenario.

I could also go back into the AIP/MIP client and remove the Confidential label from the file. So, I was puzzled at this point. I then proceeded to install Adobe Reader DC and the AIP Plug-In as described in the original article.

Download MIP Adobe Plug-In

Once that was completed, I was able to logon as the account, open the document in Adobe Reader DC AND in Edge.

File opened successfully after installing the plug-in

According to the article, you should not need the plug in or any other product to open the protected file in Edge after protection is applied. Has anyone else experienced this issue and can explain why the article is not doing as said. I would love to hear any answers you may have on this subject!

PLEASE COMMENT!
THANK YOU FOR READING!

REFERENCES:
Which PDF readers are supported for protected PDFs?
MIP plug-in for Acrobat and Acrobat Reader 
Azure Information Protection Reader

Error: Policy Is Missing when trying to load and run an AIP/MIP UL on-premises content scan

WORKAROUND UPDATE!
SEE AT END OF THIS POST!

There is a current BUG is has been filed with Microsoft that relates to AIP/MIP Scanner and running a Unified Labeling content scan on premises. The main issue is with the Security and Compliance Center and it replicating the Policies that you create for your Sensitivity Labels in your M365 Tenant.

Since these Policies will not replicate, your content scans will fail and you will see the following error within the Azure Portal under Azure Information Protection:

Error: Policy is missing in AIP

You will be able to verify that the Policies are present in the Security and Compliance Center under the Information Protection page and the Policies Page in Azure Information Protection:

NOTE: I had created my labels and label policies in Azure AIP and migrated them to Security and Compliance Center via the following LINK

What you will also notice, if you create a policy in SCC, it will NOT replicate to Azure.

Next, I checked to see if the AIP Scanner Service Account has the policies applied to it as a member recipient of the policies. It needs to so that the account can apply labels to on premises accounts through the policy.


Let’s continue troubleshooting…

The AIP Scanner account was a member of a defined policies in the Security & Compliance Center and you are still having issues:

  1. Is the AIP Scanner service started?
  2. If the answer is no, start it
  3. From PowerShell run the following:

Sample Output

It says it is scanning, but you are not getting results AND you have that Error: Policy is missing statement in the Nodes Tab of AIP.

The next thing to verify this whether or not the policy is replicating from SCC to Azure. This is done through PowerShell by running the following:

Connect to SCC PowerShell

Check the policy replication status

Sample Output
Distribution Status is in Pending

Normal replication is up to 24 hours for a change or policy addition. So, if your WhenChanged or WhenCreated values are more than 24 hours old, then they are NOT replicating. You can further verify this by running the following:

Sample Output
Replication Taking Longer Than Expected Error

What do I do next?

If you have this error, it would be best to log a support call with Microsoft and explain that you have the AIP UL Policy Replication Error. From my sources they are saying this is a known issue with the SCC and Azure that will be remediated by the end of October.

So, in the meantime, I guess we will wait!


WORKAROUND

After troubleshooting with this issue with some of my Microsoft Colleagues, I was able to get the Scanner to start scanning properly with out the error being listed in the Azure Portal. Here are the steps.

On the scanner node, right-click a file or folder and choose to protect it:

Next, within the AIP Application, choose Help and Feedback

Next, choose Reset Settings

Click Continue

Once completed, click Close, then exit the AIP application. This clears all the registry settings within the scanner node.

Now you will want to reset all the local files for the scanner

First, stop the scanner services for the scanner and network discovery

Next, navigate to the following folder for the local account that is used for AIP scanner. Example – C:\Users\AIPScanner\AppData\Local\Microsoft\MSIP
Rename or Delete the MIP folder in that MSIP directory.
(I renamed my folder to mip-old2)

Rename or Delete the mip folder

Restart the services you stopped

You should now see the scanner as Running and Working within the Azure Portal. No more errors should be listed.

Thanks to Angel Marroquin at Microsoft for the assistance on this workaround!


THANKS FOR VIEWING!
KEEP THE COMMENTS FLOWING!

REFERENCES:
Migrate AIP Policies
AIP FAQ

Installation and Configuration of Azure Information Protection Unified Labels Scanner

With the release of Unified Labeling in Azure and M365, there is now a way to protect your data and label your data appropriately for confidentiality and encryption for your files shares and files on your on premises devices. The following shows how to install the latest AIP_UL client and configure it in Azure to apply those Unified Labeling Policies.

This is a detailed process and I had some issues myself with getting the process simplified. I will do my best here to make this as smoot has possible with as many reference documents that I can input. Always feel free to comment as this data is ever changing and updating as Microsoft updates the offering.

Prerequisites

Please refer to this document for a full list of pre-requisites before deploying the scanner:

https://docs.microsoft.com/en-us/azure/information-protection/deploy-aip-scanner-prereqs

For the basics we have the following:

The prerequisites below are still required for successful AIP scanner installation.

  • A Windows Server 2012 R2 or greater Server to run the service
    • Minimum 4 CPU and 4GB RAM physical or virtual.
      NOTE: More RAM is better. The scanner will allocate RAM 2.5-3 times of size of all files being scanned in parallel. Thus, if you scan 40 files that are 20MB each at the same time, it should take about 202.540=2GB RAM. However, if you have one big 1GB file it can take 3GB of RAM just for that file.
  • Internet connectivity necessary for Azure Information Protection
  • A SQL Server 2012+ local or remote instance (Any version from Express or better is supported)
    • Sysadmin role needed to install scanner service (the user running Install-AIPScanner, not the service account)

      NOTE: If using SQL Server Express, the SQL Instance name is ServerName\SQLExpress.

      NOTE: At this time, a different SQL instance is needed for each AIP Scanner node.
  • Service account created in On Premises AD (I will call this account AIPScanner in this document).
    • Service requires Log on locally right and Log on as a service right (the second will be given during scanner service install).
    • Service account requires Read permissions to each repository for discovery and Read/Write permissions for classification/protection.
  • AzInfoProtection_UL.exe is available on the Microsoft Download Center (The scanner bits are included with the AIP Client)
  • The Azure AD Preview PowerShell module. From the machine you’re installing AIP Scanner on, run the following from an Administrator PowerShell:

Configure the scanner in the Azure portal

Before you install the scanner, or upgrade it from an older general availability version, configure or verify your scanner settings in the Azure Information Protection area of the Azure portal.

To configure your scanner:

  1. Sign in to the Azure portal with one of the following roles:
    • Compliance administrator
    • Compliance data administrator
    • Security administrator
    • Global administrator

      Then, navigate to the Azure Information Protection pane. For example, in the search box for resources, services, and docs, start typing Information and select Azure Information Protection.
  2. Create a scanner cluster. This cluster defines your scanner and is used to identify the scanner instance, such as during installation, upgrades, and other processes.
  3. Scan your network for risky repositories. Create a network scan job to scan a specified IP address or range, and provide a list of risky repositories that may contain sensitive content you’ll want to secure. Run your network scan job and then analyze any risky repositories found.
  4. Create a content scan job to define the repositories you want to scan.

Create a scanner cluster

  1. From the Scanner menu on the left, select Clusters clusters icon.
  2. On the Azure Information Protection – Clusters pane, select Add add icon.
  3. On the Add a new cluster pane, enter a meaningful name for the scanner, and an optional description. The cluster name is used to identify the scanner’s configurations and repositories. For example, you might enter Europe to identify the geographical locations of the data repositories you want to scan. You’ll use this name later on to identify where you want to install or upgrade your scanner.
  4. Select Save save icon to save your changes.
  5. On the Add a new cluster pane, enter a meaningful name for the scanner, and an optional description. The cluster name is used to identify the scanner’s configurations and repositories. For example, you might enter Europe to identify the geographical locations of the data repositories you want to scan. You’ll use this name later on to identify where you want to install or upgrade your scanner.
  6. Select Save save icon to save your changes.

Create a network scan job (public preview)

Starting in version 2.8.85.0, you can scan your network for risky repositories. Add one or more of the repositories found to a content scan job to scan them for sensitive content.

Note: The network discovery interface is currently in gradual deployment and will be available in all regions by September 15, 2020.

Network discovery prerequisites

PrerequisiteDescription
Install the Network Discovery serviceIf you’ve recently upgraded your scanner, you may need to still install the Network Discovery service.

Run the Install-MIPNetworkDiscovery cmdlet to enable network scan jobs.
Azure Information Protection analyticsMake sure that you have Azure Information Protection analytics enabled.

In the Azure portal, go to Azure Information Protection > Manage > Configure analytics (Preview).

For more information, see Central reporting for Azure Information Protection (public preview).

Creating a network scan job

  1. Log in to the Azure portal, and go to Azure Information Protection. Under the Scanner menu on the left, select Network scan jobs (Preview) network scan jobs icon.
  2. On the Azure Information Protection – Network scan jobs pane, select Add add icon.
  3. On the Add a new network scan job page, define the following settings:

    Network scan job name: Enter a meaningful name for this job. This field is required.
    Description: Enter a meaningful description.
    Select the cluster: From the dropdown, select the cluster you want to use to scan the configured network locations.

    Tip: When selecting a cluster, make sure that the nodes in the cluster you assign can access the configured IP ranges via SMB.

    Configure IP ranges to discover: Click to define an IP address or range.

    In the Choose IP ranges pane, enter an optional name, and then a start IP address and end IP address for your range.

    Tip: To scan a specific IP address only, enter the identical IP address in both the Start IP and End IP fields.

    Set schedule: Define how often you want this network scan job to run.

    If you select Weekly, the Run network scan job on setting appears. Select the days of the week where you want the network scan job to run.
    Set start time (UTC): Define the date and time that you want this network scan job to start running. If you’ve selected to run the job daily, weekly, or monthly, the job will run at the defined time, at the recurrence you’ve selected.

    Note: Be careful when setting the date to any days at the end of the month. If you select 31, the network scan job will not run in any month that has 30 days or fewer.
  4. Select Save save icon to save your changes.

 Tip: If you want to run the same network scan using a different scanner, change the cluster defined in the network scan job. Return to the Network scan jobs pane, and select Assign to cluster to select a different cluster now, or Unassign cluster to make additional changes later.

Analyze risky repositories found

Repositories found, either by a network scan job, a content scan job, or by user access detected in log files, are aggregated and listed on the Scanner > Repositories repositories icon pane.

If you’ve defined a network scan job and have set it to run at a specific date and time, wait until it’s finished running to check for results. You can also return here after running a content scan job to view updated data.

  1. Under the Scanner menu on the left, select Repositories repositories icon.
    The repositories found are shown as follows:
    • The Repositories by status graph shows how many repositories are already configured for a content scan job, and how many are not.
    • The Top 10 unmanaged repositories by access graph lists the top 10 repositories that are not currently assigned to a content scan job, as well as details about their access levels. Access levels can indicate how risky your repositories are.
  2. Do any of the following:
    columns icon Select Columns to change the table columns displayed.
    refresh icon If your scanner has recently run network scan results, select Refresh to refresh the page.
    add icon Select one or more repositories listed in the table, and then select Assign Selected Items to assign them to a content scan job.
    Filter The filter row shows any filtering criteria currently applied. Select any of the criteria shown to modify its settings, or select Add Filter to add new filtering criteria. Select Filter to apply your changes and refresh the table with the updated filter.
    Log Analytics icon In the top-right corner of the unmanaged repositories graph, click the Log Analytics icon to jump to Log Analytics data for these repositories.

Repositories with public access

Repositories where Public access is found to have read or read/write capabilities may have sensitive content that must be secured. If Public access is false, the repository not accessible by the public at all.

Public access to a repository is only reported if you’ve set a weak account in the StandardDomainsUserAccount parameter of the Install-MIPNetworkDiscovery or Set-MIPNetworkDiscovery cmdlets.

  • The accounts defined in these parameters are used to simulate the access of a weak user to the repository. If the weak user defined there can access the repository, this means that the repository can be accessed publicly.
  • To ensure that public access is reported correctly, make sure that the user specified in these parameters is a member of the Domain Users group only.

Create a content scan job

Deep dive into your content to scan specific repositories for sensitive content.

You may want to do this only after running a network scan job to analyze the repositories in your network, but can also define your repositories yourself.

  1. Under the Scanner menu on the left, select Content scan jobs.
  2. On the Azure Information Protection – Content scan jobs pane, select Add add icon.
  3. For this initial configuration, configure the following settings, and then select Save but do not close the pane.

    Content scan job settings
    – Schedule: Keep the default of Manual
    – Info types to be discovered: Change to Policy only
    – Configure repositories: Do not configure at this time because the content scan job must first be saved.

    Policy enforcement
    Enforce: Select Off
    – Label files based on content: Keep the default of On
    – Default label: Keep the default of Policy default
    – Relabel files: Keep the default of OffConfigure file settings– Preserve “Date modified”, “Last modified” and “Modified by”: Keep the default of On
    – File types to scan: Keep the default file types for Exclude
    – Default owner: Keep the default of Scanner Account
  4. Now that the content scan job is created and saved, you’re ready to return to the Configure repositories option to specify the data stores to be scanned. Specify UNC paths, and SharePoint Server URLs for SharePoint on-premises document libraries and folders. 

    Note: SharePoint Server 2019, SharePoint Server 2016, and SharePoint Server 2013 are supported for SharePoint. SharePoint Server 2010 is also supported when you have extended support for this version of SharePoint.

    To add your first data store, while on the Add a new content scan job pane, select Configure repositories to open the Repositories pane:Configure data repositories for the Azure Information Protection scanner
    1. On the Repositories pane, select Add:

      Add data repository for the Azure Information Protection scanner
    2. On the Repository pane, specify the path for the data repository, and then select Save.
      • For a network share, use \\Server\Folder.
      • For a SharePoint library, use http://sharepoint.contoso.com/Shared%20Documents/Folder.
      • For a local path: C:\Folder
      • For a UNC path: \\Server\Folder 

        Note: Wildcards are not supported and WebDav locations are not supported.
    3. If you add a SharePoint path for Shared Documents:
      • Specify Shared Documents in the path when you want to scan all documents and all folders from Shared Documents.
        For example: http://sp2013/SharedDocuments
      • Specify Documents in the path when you want to scan all documents and all folders from a subfolder under Shared Documents.
        For example: http://sp2013/Documents/SalesReports
        or, specify only the FQDN of your SharePoint,
        For example http://sp2013 to discover and scan all SharePoint sites and subsites under a specific URL and subtitles under this URL.
      • Grant scanner Site Collector Auditor rights to enable this.
      • For the remaining settings on this pane, do not change them for this initial configuration, but keep them as Content scan job default. The default setting means that the data repository inherits the settings from the content scan job.

        Use the following syntax when adding SharePoint paths:
        Root path: http://<SharePoint server name>

        Scans all sites, including any site collections allowed for the scanner user.
        Requires additional permissions to automatically discover root content

        Specific SharePoint subsite or collection:
        One of the following:
        – http://<SharePoint server name>/<subsite name>
        – http://SharePoint server name>/<site collection name>/<site name>


        Requires additional permissions to automatically discover site collection content

        Specific SharePoint library:
        One of the following:
        – http://<SharePoint server name>/<library name>
        – http://SharePoint server name>/.../<library name>


        Specific SharePoint folder: http://<SharePoint server name>/.../<folder name>
  5. Repeat the previous steps to add as many repositories as needed.
  6. When you’re done, close both the Repositories and Content scan job panes.

Back on the Azure Information Protection – Content scan job pane, your content scan name is displayed, together with the SCHEDULE column showing Manual and the ENFORCE column is blank.

You’re now ready to install the scanner with the content scanner job that you’ve created. Continue with Scanner Installation.

Scanner Installation

Now that we have verified that all prerequisites and configured the AIP in Azure, we can go through the basic scanner install.

  1. Log onto the server where you will install the AIP Scanner service using an account that is a local administrator of the server and has permission to write to the SQL Server master database. (more restrictive scenarios are documented in the official documentation)
  2. Run AzInfoProtection_UL.exe on the server and step through the client install (this also drops the AIP Scanner bits).
    WARNING: This blog is based on the current version of the AIP Client.  If you want to update to the Preview client, please install the GA first and then install the preview client and use Update-AIPScanner after installation.
  3. Next, open an Administrative PowerShell prompt.
  4. At the PowerShell prompt, type the following command and press Enter:

undefined
Output from Scanner Installation in PowerShell

Create Cloud Service Account

If you are not using Azure AD Sync for your Service account, you will need to create a service account in the cloud tenant to use for AIP authentication. If you have synced your on premises service account, you can skip this task.

  1. Run the command below to connect to Azure AD.

  1. When prompted, provide tenant Global Admin credentials.
  2. To create an account in the cloud, you must first define a password profile object. Run the commands below to define this object.

  1. When prompted, enter a password for the cloud service account.
  2. To create the account, run the commands below.

  1. When prompted, enter the tenant name you want to use for the UserPrincipalName for the cloud service account (e.g. tenant.onmicrosoft.com).

Creating the Azure AD Application in Azure

Next, we will configure the App Registration for the Web App that is required to run the Set-AIPAuthentication command that will be used to get the authentication token. We will also assign the necessary Oauth2Permissions for the Web App to have delegated rights to the App.

  1. Run the commands below to create the Web App, associated Service Principal, and key password.

  1. Next, we need to run some commands to build the RequiredResourceAccess object that is needed to automate delegation of permissions for the native application.

  1. Now we can create the App and associated Service Principal using the commands below.

Authenticating as the AIP Scanner Service

In this task, we will use the command created previously to authenticate the AIP Scanner to the AIP Service.

  1. Open PowerShell using Run as a different user and use the on premises Scanner Service account which should have Run As Administrator rights.

    undefined
  1. Run the commands in the following PowerShell session with the Run as Administrator option, which is required for the OnBehalfOf parameter.
    • The first command creates a PSCredential object and stores the specified Windows user name and password in the $pscreds variable. When you run this command, you are prompted for the password for the user name that you specified.
    • The second command acquires an access token that is combined with the application so that the token becomes valid for 1 year, 2 years, or never expires, according to your configuration of the registered app in Azure AD. The user name of scanner@contoso.com sets the user context to download labels and label policies from your labeling management center, such as the Office 365 Security & Compliance Center.

Successful OUTPUT:
Acquired application access token on behalf of DOMAIN\scanner

  1. Last Step is to Restart the AIP Scanner Service

Look to these reference documents for further details:
Set-AIPAuthentication
Get Azure AD Token for the AIP Scanner

Configure the scanner to apply classification and protection

The default settings configure the scanner to run once, and in reporting-only mode.

To change these settings, edit the content scan job:

  1. In the Azure portal, on the Azure Information Protection – Content scan jobs pane, select the cluster and content scan job to edit it.
  2. On the Content scan job pane, change the following, and then select Save:
    • From the Content scan job section: Change the Schedule to Always
    • From the Policy enforcement section: Change Enforce to On 

      Tip: You may want to change other settings on this pane, such as whether file attributes are changed and whether the scanner can relabel files. Use the information popup help to learn more information about each configuration setting.
  3. Make a note of the current time and start the scanner again from the Azure Information Protection – Content scan jobs pane:

    Initiate scan for the Azure Information Protection scanner

    Alternatively, run the following command in your PowerShell session:

The scanner is now scheduled to run continuously. When the scanner works its way through all configured files, it automatically starts a new cycle so that any new and changed files are discovered.

MUCH MORE TO COME! CHECK OFTEN AND SEND COMMENTS!

REFERENCES:
AIP Prerequisites
Install and Configure AIP UL Application
AIP UL Client Download
AIP Classic Client Express Installation

Changing the M365 Tenant Security Defaults through Azure

Microsoft has put out a new standard for security defaults in a tenant that harden default settings in the org. Security defaults make it easier to help protect your organization from these attacks with preconfigured security settings:

  • Requiring all users to register for Azure Multi-Factor Authentication.
  • Requiring administrators to perform multi-factor authentication.
  • Blocking legacy authentication protocols.
  • Requiring users to perform multi-factor authentication when necessary.
  • Protecting privileged activities like access to the Azure portal.

Now, there might be many reasons why you would not want these defaults enabled in your tenant, just remember that you will need to setup these things manually should you change the security defaults setting.

How to change security defaults in Azure/M365

  • Log into https://portal.azure.com with your Global Admin account.
  • Click on Azure Active Directory to navigate to that pane.
  • In the list to the left, click Properties.
  • Scroll to the bottom of the screen on the right and click Manage Security Defaults
  • Make the appropriate change: YES/NO
  • (IMPORTANT) Save the changes by clicking the Save button
Manage Security Defaults for Tenant AAD

This should set the defaults for your O365 tenant as you wish to have them. Please refer to the references below for more information and detail into each of the security defaults.

MORE POSTS TO COME ON SECURITY AND COMPLIANCE!
HAVE A WONDERFUL DAY!

REFERENCES:
What Are Security Defaults?
Setup Multi-Factor Authentication
Security Defaults

Using RDP to access an Azure AD Domain Joined Computer

I have a VM that is joined to my Azure AD test tenant domain. I was having issues using RDP to access the box with my Azure AD credentials (username@tenant.onmicrosoft.com). I kept getting the following when trying to connect:

Azure AD Credentials would not work to RDP to the client.

So I started researching and found that this was an common issue that many have started to face with their Azure AD Joined machines. Unfortunately, at this time it isn’t quite as easy as “open up a new RDP connection, type in the computer, type my email, and connect”.  Here are the steps to connect a session to that Azure AD joined computer.

Steps to connect RDP to an Azure AD joined computer.

First, open remote desktop as if you were going to connect to any other computer. Type in the computer name or IP address and expand the the Show Options section. Next, click the Save As button to save the RDP file to your computer. At this point you can close the Remote Desktop Connection window as it isn’t needed any longer.

Next, open Notepad. Click File -> Open -> location your RDP file that was saved in the previous step. 

Go to the very bottom of the list of parameters and add the following two lines:

enablecredsspsupport:i:0
authentication level:i:2

Save the changes to the .rdp file

NOTE: You can also add your username that will be used to connect to the session in the file as well:

username:s:.\AzureAD\YOURusername@YOURtenantname.onmicrosoft.com

Example RDP File

Now you are ready to connect! Double click on the RDP file and connect to the Azure AD Joined computer.

KEEP RESEARCHING!
STAY POSITIVE! THE WORLD WILL CHANGE FOR THE BETTER FOR ALL OF US!

REFERENCES:
Remote Desktop to Azure AD Joined Computer

Connect an MCT Credited Azure Subscription to separate Azure Tenant

As many of you know I have an existing Azure/M365 Tenant that I use with my company as many of you all do as well. When you get an MCT Certification, you get access to a monthly credit in Azure.

So I clicked on Activate and when activating the subscription, it created a new Azure tenant that was linked to my MCP ID and not my LDLNET ID. The problem here was that my Microsoft Identity was a different email address (@live.com) from my tenant Microsoft Identity (@ldlnet.net).

So now I have a new tenant that I really don’t need, so I started thinking, could I transfer the subscription to my LDLNET tenant and keep the monthly credit. The answer is Yes AND No.

Here is what I had to do to transfer the subscription to my LDLNET Directory

First, I created a guest account in my LDLNET tenant for the @live.com email address and then temporarily gave the account Global Admin privileges. This was so that I could access the subscription when transferred and assure that the proper accounts that needed subsequent access to the subscription get what the owner permissions by logging on with the @live.com account in the LDLNET tenant. I then activate the account in LDLNET.

NOTE: This is probably NOT the most secure option to start, but I will update as I find the article’s that define least privilege for setting this up. I’ve seen a couple of articles, but it wasn’t the exact same way. The thing here is that the billing cannot be transferred since it is being handled by Microsoft Directly with the credits. So, I have to keep the @live.com account active in the LDLNET tenant so that it bills correctly.

Next, I go to the setup tenant and look at the subscription Overview:

At the top of the screen, I choose Change Directory. Since my @Live.com account was an admin for the LDLNET Directory now, I could choose the directory on the following screen:

Change Directory to the destination tenant.

NOTE: I couldn’t change the billing on the setup tenant nor transfer it since it was through Microsoft, but why would I want to anyway since it’s my credit that was given to me monthly. Also, on my visual studio subscription, I made sure that my @ldlnet.net address was an alternate access account on the subscription. I want to make sure the credit stays after this month!!

So, I received the email asking to accept the transfer and clicked Accept The Transfer:

Accept The Transfer E-Mail

Once the subscription was accepted and transferred to LDLNET, I logged into LDLNET tenant with my @Live.com account. I then went to the subscription and made sure to add all necessary accounts to the subscription so that they would get access:

Once completed, I logged in with my Original Global Admin account and changed the @Live.com account permissions to a Global Reader in my LDLNET tenant, then gave them Owner Access permissions to the Subscription specifically.

And that has completed the transfer. Hopefully, the subscription will continue with the monthly credit as per my MCT Certification allows. I will update if something changes. If you have a better way to do this, please comment and I will be happy to verify it and post!

KEEP THE COMMENTS COMING!
THANKS FOR READING!

New Certification Achieved Today

I have been working on updating my skillset to M365 and passed the final exam today to achieve it. I am hoping that the certification will assist me with attaining work moving forward.

You can verify at the following URL:
https://www.youracclaim.com/badges/8bb7d636-b898-43ec-b283-0dea03586896/public_url

MAINTAIN POSITIVE ATTITUDE!
SUCCESS WILL ARRIVE IN DUE TIME!

Remote Desktop Licensing Mode is Not Configured when configuring Remote Desktop Services

I recently setup a backend RDP server so that I could test our remote services. I went through the installation process and installed my RDP license on the server successfully. The problem was that I was not getting an error when logging onto the server locally to check the status of the RDP Server:

remote desktop licensing mode is not configured
Error Example for RDP Licensing

I also had Events within Event Viewer:

Log Name: System
Source: Microsoft-Windows-TerminalServices-Licensing
Date: 6/24/2020 3:44:16 PM
Event ID: 18
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: SRV2016-02.ldlnet.net
Description:
The Remote Desktop license server “SRV2016-02” has not been activated and therefore will only issue temporary licenses. To issue permanent licenses, the Remote Desktop license server must be activated.

Usually, this error appears as a notification popup in the bottom right-hand corner of the screen saying:

Remote Desktop licensing mode is not configured
Remote Desktop Services will stop working in xx days. On the RD Connection Broker server, use Server Manager to specify the Remote Desktop licensing mode and the license server.

And when you click on this notification popup, it doesn’t redirect you anywhere and it gets simply disappeared which is a quite frustrating situation.

I thought I had this set properly, but the RDP Licensing Diagnoser application told me that I needed to choose the licensing configuration to distribute for Per Device OR Per User. The licenses I installed were per device so I did some research.

I found out that this had to be configured via the Registry, PowerShell, or could be configured through GPO. I chose to do GPO since that would always apply on my servers in my domain.


How To configure the Remote Desktop Licensing Mode through the Registry

Here’s how to change the licensing mode for Remote Desktop session host using the registry editor and get rid of the error message Remote Desktop Services will stop working in xx days:

At first, press Windows + R keys together and then type regedit in the Run dialog box and press Enter key.

regedit windows 10

Next, in the left pane of the Registry Editor, navigate to the following registry key:

licensing mode for the remote desktop session host is not configured

Next in the right pane, double-click on the LicensingMode to edit its value and then change the Value data according to your requirement:

Set the Value data 2 for Per Device RDS licensing mode
Set the Value data 4 for Per User RDS licensing mode

remote desktop services will stop working

Finally, click on the OK button to save the changes.

Now, restart your computer and check if the Remote Desktop licensing mode is not configured issue on Windows Server has been resolved or not.

Once you changed the licensing mode, now everything will be reported accurately and the Remote Desktop session host will recognize the licensing configuration.


How To configure the Remote Desktop Licensing Mode through a Group Policy Object (GPO)

First Logon to a machines that has Group Policy Tools Installed, press Windows + R keys together, type gpedit.msc, and press Enter key.

gpedit-windows-10

Within Group Policy Editor, create a new GPO and link it to the level that you need to link it to. (In my case, the domain level.) Navigate to:

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing.

change remote desktop licensing mode

Next, double-click on the “Use the specified Remote Desktop license servers” setting and then select Enabled option. Finally, enter the names of the license servers (host name or IP address) and then click on the OK button.

use the specified remote desktop license servers

Similarly, double-click on the “Set the Remote Desktop licensing mode” setting and then select Enabled option. Finally, set the licensing mode (Per Device or Per User) and then click on the OK button.

set the remote desktop licensing mode

Once all these changes are done, close Group Policy Editor, go to the RDP Licensing Server and run a gpupdate /force to refresh Group Policy.

Now, when you open the Remote Desktop Licensing Diagnoser, you shouldn’t see any errors like the remote desktop licensing mode is not configured on windows server or any kind of issues regarding your licenses.

Corrected Licensing Diagnoser Result

How To configure Remote Desktop Licensing Mode through PowerShell

You can also use PowerShell to set the Licensing Mode via the Set-RDLicenseConfiguration cmdlet from the RemoteDesktop PowerShell Module which is installed with Remote Desktop Services:


KEEP POSITIVITY ON YOUR SIDE!
CONTINUE TO LEARN!

REFERENCES:
How to Fix Remote Desktop Licensing Mode is Not Configured
Set-RDLicenseConfiguration

Grant an External User Guest Access to your M365 Tenant

Microsoft365 allows the tenant administrators to grant external users access to content in their tenant by setting them up as a guest in their M365 Tenant. Microsoft365 provides a guest access feature that you can use to grant content access to contractors, partners or others who need access to certain content.

However, the process of setting up a guest user works differently from that of setting up a normal, licensed user from within your organization.

By default, Microsoft365 Admin Center contains a Guest Users screen. You will also notice, however, that this screen does not contain an option to create a guest user. In fact, the only things that you can do are search for a user or delete a user.

Limited Access to Administrate Guest Users in M365

Being that the Guest Users screen doesn’t give you a way to create a guest user, you will need to either delve into PowerShell or perform the task within Azure Active Directory. I prefer using PowerShell, and will write a post about how to perform this via PowerShell, but unless you need to create a large number of guest users, it is usually going to be easier to use the GUI. Below is how to create a guest user via Azure AD.

To create a guest user, expand the Admin Centers container and then click on Azure Active Directory. When the Azure Active Directory Admin Center opens, click on the Users container. You can see that just to the right of the New User option, there is an option to create a New Guest User.

Create New Guest User

NOTE: Creating a guest user account isn’t like creating a normal user account. Rather than providing the account details and clicking a Create button, you will instead need to send an invitation to the user.

Make Sure You Verify Their E-Mail Address Beforehand!!!

Choose Invite User > Enter the Identity Information

Initial Data Entry

Next Enter A Personal Message (optional) > Choose their Group Membership > Update any AAD or M365 Permissions under Roles > Update their Sign In Settings > Click Invite to send the invitation

Enter Data and Settings Then Click Invite Button

After a few minutes, the specified user will receive an e-mail invitation that looks something like the one shown below. The recipient will need to click the Accept Invitation button and accept the terms of use.

Example of Email Generated Invitation

When the guest user completes the registration process, they are logged into Microsoft365 however, there are no applications initially available to the user. This is because unlike a standard user, external users do not automatically get access to applications.

User Has Verified Access and Accepted the Invitation

If you go back to the Guest Users screen, you will see the newly created guest user listed (you may have to refresh the screen). As previously noted, you can’t do much from this screen. You can, however, click on the user to see a few extra details now. Example is below.

More Details Available

The way that you grant an external user access to data is to add the user to a group that has access to the data. Let’s suppose, for example, that for whatever reason, you need to add an external user to a Teams Group named Microsoft Exchange Guys. To do so, you would go to the Groups folder within the Microsoft 365 Admin Center, click on the Microsoft Exchange Guys group, and then edit the Membership list, as shown below.

After clicking the Edit button, click on Add Members and then select the external user that you wish to add. Click Save to complete the process,

The New Guest User Will Show When Searching To Add Users To The Group

If you now go back to the Group’s membership, you are able to see the Microsoft Exchange Guys group membership showing the new guest user as a member.

Guest User Has Been Added To The Group

Granting access in this way does not provide the external user with blanket access to the Teams Group. However, another group member is now able to e-mail the external user a link to the Teams Group. The external user can use this link to access the Group within the Teams app.

User is now in Teams Group

NOTE: Keep in mind that I am only using the Teams Group as an example. You can use somewhat similar techniques to provide access to a variety of Microsoft365 AND Azure AD content.

MORE M365 CONTENT TO COME!
POSITIVE ATTITUDE = POSITIVE RESULTS

REFERENCES:
How To Enable Guest Access for Office 365

Windows Server Core – How to have PowerShell automatically start when logging onto the session.

In my environment, I have a Windows Server (2019) Core edition server installed with Exchange 2019. Most of the time, I have to get on the server to run PowerShell commands for maintenance purposes, etc…

Well, by default, Windows Server Core opens the command prompt when you logon and then I have to manually open PowerShell from there to run cmdlets, etc…

However, if you would like to change the default cmd to PowerShell, you can change it by changing the Registry value.

The Registry that I’m talking is located under the following location:

Change the Shell Value in the Registry

The easiest way I see to change the value is to use the Set-ItemProperty cmdlet within PowerShell.

Open Windows PowerShell within Server Core command prompt. You can type “PowerShell” on your command prompt.

Then, enter the following command on PowerShell console and hit enter:

Once completed, you will need to reboot the computer from PowerShell:

When the computer has rebooted and you have logged on, PowerShell should load by default instead of Command Prompt.

EVEN MORE INFORMATION

Now, since I have an Exchange Server installed on this server, there is a Command in the $bin directory called LaunchEMS.cmd that will load the Exchange Management Shell for you. So instead of loading just PowerShell, I tell WinLogon to load Exchange Management Shell so that I do not have to do any additional typing or searching for EMS on the box. Remember, Server Core has no GUI!

I run the same commands as above, but just change the value to LaunchEMS.cmd

Then Restart the Computer:

Once Rebooted, you can logon and EMS will be the only window prompt that loads in the shell!

Exchange Management Shell loads when you logon

NOTE: You can always run cmd from the prompt to open Command Prompt and also run PowerShell.exe to open regular PowerShell from the EMS Session Window.

REMAIN POSITIVE!
THANKS FOR READING!

REFERENCES:
Windows Server Core: How to start PowerShell by Default