Documentation Restructure
All checks were successful
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 5s
All checks were successful
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 5s
This commit is contained in:
@@ -0,0 +1,78 @@
|
||||
---
|
||||
tags:
|
||||
- Microsoft Exchange
|
||||
- Lets Encrypt
|
||||
- Email
|
||||
---
|
||||
|
||||
**Purpose**: If you want to set up automatic Let's Encrypt SSL certificates on a Microsoft Exchange server, you have to go through a few steps to install the WinACME bot, and configure it to automatically renew certificates.
|
||||
|
||||
!!! note "ACME Bot Provisioning Considerations"
|
||||
This document assumes you want a fully-automated one-liner command for configuring the ACME Bot, it is also completely valid to go step-by-step through the bot to configure the SSL certificate, the IIS server, etc, and it will automatically create a Scheduled Task to renew on its own. The whole process is very straight-forward with most answers being the default option.
|
||||
|
||||
### Download the Win-ACME Bot:
|
||||
|
||||
* Log into the on-premise Exchange Server via Datto RMM
|
||||
* Navigate to: [https://www.win-acme.com/](https://www.win-acme.com/)
|
||||
* On the top-right of the website, you will see a "**Download**" button with the most recent version of the Win-ACME bot
|
||||
* Extract the contents of the ZIP file to "**C:\\Program Files (x86)\\Lets Encrypt**"
|
||||
* Make the "**Lets Encrypt**" folder if it does not already exist
|
||||
|
||||
### Configure `settings_default.json`:
|
||||
|
||||
* The next step involves us making a modification to the configuration of the Win-ACME bot that allows us to export the necessary private key data for Exchange
|
||||
* Using a text editor, open the "**settings\_default.json**" file
|
||||
* Look for the setting called "**PrivateKeyExportable**" and change the value from "**false**" to "**true**"
|
||||
* Save and close the file
|
||||
|
||||
### Download and Install the SSL Certificate:
|
||||
|
||||
* Open an administrative Command Line (DO NOT USE POWERSHELL)
|
||||
* Navigate to the Let's Encrypt bot directory: `CD "C:\Program Files (x86)\Lets Encrypt"`
|
||||
* Invoke the bot to automatically download and install the certificate into the IIS Server that Exchange uses to host the Exchange Server
|
||||
* Be sure to change the placeholder subdomains to match the domain of the actual Exchange Server
|
||||
* (e.g. "**mail.example.org**" | "**autodiscover.example.org**")
|
||||
```
|
||||
wacs.exe --target manual --host mail.example.org,autodiscover.example.org --certificatestore My --acl-fullcontrol "network service,administrators" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'" --verbose
|
||||
```
|
||||
|
||||
* When the command is running, it will ask for an email address for alerts and abuse notifications, just put "**infrastructure@bunny-lab.io**"
|
||||
* If you run into any unexpected errors that result in anything other than exiting with a status "0", consult with Nicole Rappe to proceed
|
||||
* Check that the domain of the Exchange Server is reachable on port 80 as Let's Encrypt uses this to build the cert.
|
||||
* Searching the external IP of the server on [Shodan](https://www.shodan.io/) will reveal all open ports.
|
||||
|
||||
### Troubleshooting:
|
||||
If you find that any of the services such as [https://mail.example.org/ecp](https://mail.example.org/ecp), [https://autodiscover.example.org](https://autodiscover.example.org), or [https://mail.example.org/owa](https://mail.example.org/owa) do not let you log in, proceed with the steps below to correct the "Certificate Binding" in IIS Manager:
|
||||
|
||||
* Open "**Server Manager**" > Tools > "**Internet Information Services (IIS) Manager**"
|
||||
* Expand the "**Connections**" server tree on the left-hand side of the IIS Manager
|
||||
* Expand the "**Sites**" folder
|
||||
* Click on "**Default Web Site**"
|
||||
* On the right-hand Actions menu, click on "**Bindings...**"
|
||||
* A table will appear with different endpoints on the Exchange server > What you are looking for is an entry that looks like the following:
|
||||
* **Type**: https
|
||||
* **Host Name**: autodiscover.example.org
|
||||
* **Port**: 443
|
||||
* Double-click on the row, or click one then click the "**Edit**" button to open the settings for that endpoint
|
||||
* Under "**SSL Certificate**" > Make sure the certificate name matches the following format: "**\[Manual\] autodiscover.example.org @ YYYY/MM/DD**"
|
||||
* If it does not match the above, use the dropdown menu to correct it and click the "**OK**" button
|
||||
* **Type**: https
|
||||
* **Host Name**: mail.example.org
|
||||
* **Port**: 443
|
||||
* Repeat the steps seen above, except this time for "**mail.example.org**"
|
||||
* Click on "**Exchange Back End**"
|
||||
* On the right-hand Actions menu, click on "**Bindings...**"
|
||||
* A table will appear with different endpoints on the Exchange server > What you are looking for is an entry that looks like the following:
|
||||
* **Type**: https
|
||||
* **Host Name**: <blank>
|
||||
* **Port**: 444
|
||||
* Repeat the steps seen above, ensuring that the "**\[Manual\] autodiscover.example.org @ YYYY/MM/DD**" certificate is selected and applied
|
||||
* Click the "**OK**" button
|
||||
* On the left-hand menu under "**Connections**" in IIS Manager, click on the server name itself
|
||||
* (e.g. "**EXAMPLE-EXCHANGE (DOMAIN\\dptadmin**")
|
||||
* On the right-hand "**Actions**" menu > Under "Manage Server" > Select "Restart"
|
||||
* Wait for the IIS server to restart itself, then try accessing the webpages for Exchange that were exhibiting issues logging in
|
||||
|
||||
### Additional Documentation:
|
||||
|
||||
* [https://www.alitajran.com/install-free-lets-encrypt-certificate-in-exchange-server/](https://www.alitajran.com/install-free-lets-encrypt-certificate-in-exchange-server/)
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
tags:
|
||||
- Microsoft Exchange
|
||||
- Email
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document is meant to be an abstract guide on what to do before installing Cumulative Updates on Microsoft Exchange Server. There are a few considerations that need to be made ahead of time. This list was put together through shere brute-force while troubleshooting an update issue for a server on 12/16/2024.
|
||||
|
||||
!!! abstract "Overview"
|
||||
We are looking to add an administrative user to several domain security groups, adjust local security policy to put them into the "Manage Auditing and Security Logs" security policy, and run the setup.exe included on the Cumulative Update ISO images within a `SeSecurityPrivilege` operational context.
|
||||
|
||||
## Domain Group Membership
|
||||
You have to be logged in with a domain user that possesses the following domain group memberships, if these group memberships are missing, the upgrade process will fail.
|
||||
|
||||
- `Enterprise Admins`
|
||||
- `Schema Admins`
|
||||
- `Organization Management`
|
||||
|
||||
## User Rights Management
|
||||
You have to be part of the "**Local Policies > User Rights Assignment > "Manage Auditing and Security Logs**" security policy. You can set this via group policy management or locally on the Exchange server via `secpol.msc`. This is required for the "Monitoring Tools" portion of the upgrade.
|
||||
|
||||
It's recommended to reboot the server after making this change to be triple-sure that everything was applied correctly.
|
||||
|
||||
!!! note "Security Policy Only Required on Exchange Server"
|
||||
While the `Enterprise Admins`, `Schema Admins`, and `Organization Management` security group memberships are required on a domain-wide level, the security policy membership for "Manage Auditing and Security Logs" mentioned above is only required on the Exchange Server itself. You can create a group policy that only targets the Exchange Server to add this, or you can make your user a domain-wide member of "Manage Auditing and Security Logs" (Optional). If no existing policies are in-place affecting the Exchange server, you can just use `secpol.msc` to manually add your user to this security policy for the duration of the upgrade/update (or leave it there for future updates).
|
||||
|
||||
## Running Updater within `SeSecurityPrivilege` Operational Context
|
||||
At this point, you would technically be ready to invoke `setup.exe` on the Cumulative Update ISO image to launch the upgrade process, but we are going to go the extra mile to manually "Enable" the `SeSecurityPrivilege` within a Powershell session, then use that same session to invoke the `setup.exe` so the updater runs within that context. This is not really necessary, but something I added as a "hail mary" to make the upgrade successful.
|
||||
|
||||
### Open Powershell ISE
|
||||
The first thing we are going to do, is open the Powershell ISE so we can copy/paste the following powershell script, this script will explicitely enable `SeSecurityPrivilege` for anyone who holds that privilege within the powershell session.
|
||||
|
||||
!!! warning "Run Powershell ISE as Administrator"
|
||||
In order for everything to work correctly, the ISE has to be launched by right-clicking "Run as Administrator", otherwise it is guarenteed that the updater application will fail at some point.
|
||||
|
||||
```powershell title="SeSecurityPrivilege Enablement Script"
|
||||
# Create a Privilege Adjustment
|
||||
$definition = @"
|
||||
using System;
|
||||
using System.Runtime.InteropServices;
|
||||
|
||||
public class Privilege
|
||||
{
|
||||
const int SE_PRIVILEGE_ENABLED = 0x00000002;
|
||||
const int TOKEN_ADJUST_PRIVILEGES = 0x0020;
|
||||
const int TOKEN_QUERY = 0x0008;
|
||||
const string SE_SECURITY_NAME = "SeSecurityPrivilege";
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError = true)]
|
||||
public static extern bool OpenProcessToken(IntPtr ProcessHandle, int DesiredAccess, out IntPtr TokenHandle);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
|
||||
public static extern bool LookupPrivilegeValue(string lpSystemName, string lpName, out long lpLuid);
|
||||
|
||||
[DllImport("advapi32.dll", SetLastError = true)]
|
||||
public static extern bool AdjustTokenPrivileges(IntPtr TokenHandle, bool DisableAllPrivileges, ref TOKEN_PRIVILEGES NewState, int BufferLength, IntPtr PreviousState, IntPtr ReturnLength);
|
||||
|
||||
[StructLayout(LayoutKind.Sequential, Pack = 1)]
|
||||
public struct TOKEN_PRIVILEGES
|
||||
{
|
||||
public int PrivilegeCount;
|
||||
public long Luid;
|
||||
public int Attributes;
|
||||
}
|
||||
|
||||
public static bool EnablePrivilege()
|
||||
{
|
||||
IntPtr tokenHandle;
|
||||
TOKEN_PRIVILEGES tokenPrivileges;
|
||||
|
||||
if (!OpenProcessToken(System.Diagnostics.Process.GetCurrentProcess().Handle, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, out tokenHandle))
|
||||
return false;
|
||||
|
||||
if (!LookupPrivilegeValue(null, SE_SECURITY_NAME, out tokenPrivileges.Luid))
|
||||
return false;
|
||||
|
||||
tokenPrivileges.PrivilegeCount = 1;
|
||||
tokenPrivileges.Attributes = SE_PRIVILEGE_ENABLED;
|
||||
|
||||
return AdjustTokenPrivileges(tokenHandle, false, ref tokenPrivileges, 0, IntPtr.Zero, IntPtr.Zero);
|
||||
}
|
||||
}
|
||||
"@
|
||||
|
||||
Add-Type -TypeDefinition $definition
|
||||
[Privilege]::EnablePrivilege()
|
||||
```
|
||||
|
||||
### Validate Privilege
|
||||
At this point, we now have a powershell session operating with the `SeSecurityPrivilege` privilege enabled. We want to confirm this by running the following commands:
|
||||
|
||||
```powershell
|
||||
whoami # (1)
|
||||
whoami /priv # (2)
|
||||
```
|
||||
|
||||
1. Output will appear similar to "bunny-lab\nicole.rappe", prefixing the username of the person running the command with the domain they belong to.
|
||||
2. Reference the privilege table seen below to validate the output of this command matches what you see below.
|
||||
|
||||
| **Privilege Name** | **Description** | **State** |
|
||||
| :--- | :--- | :--- |
|
||||
| `SeSecurityPrivilege` | Manage auditing and security log | Enabled |
|
||||
|
||||
### Execute `setup.exe`
|
||||
Finally, at the last stage, we mount the ISO file for the Cumulative Update ISO (e.g. 6.6GB ISO image), and using this powershell session we made above, we navigate to the drive it is running on, and invoke setup.exe, causing it to run under the `SeSecurityPrivilege` operational state.
|
||||
|
||||
```powershell
|
||||
D: <ENTER> # (1)
|
||||
.\Setup.EXE /m:upgrade /IAcceptExchangeServersLicenseTerms_DiagnosticDataON # (2)
|
||||
```
|
||||
|
||||
1. Replace this drive letter with whatever letter was assigned when you mounted the ISO image for the Exchange Updater.
|
||||
2. This launches the Exchange updater application. Be patient and give it time to launch. At this point, you should be good to proceed with the update. You can optionally change the argument to `/IAcceptExchangeServersLicenseTerms_DiagnosticDataOFF` if you do not need diagnostic data.
|
||||
|
||||
!!! success "Ready to Proceed with Updating Exchange"
|
||||
At this point, after doing the three sections above, you should be safe to do the upgrade/update of Microsoft Exchange Server. The installer will run its own readiness checks for other aspects such as IIS Rewrite Modules and will give you a link to download / upgrade it separately, then giving you the option to "**Retry**" after installing the module for the installer to re-check and proceed.
|
||||
|
||||
## Post-Update Health Checks
|
||||
After the update(s) are installed, you will likely want to check to ensure things are healthy and operational, validating mail flow in both directions, running `Get-Queue` to check for backlogged emails, etc.
|
||||
|
||||
!!! note "Under Construction"
|
||||
This section is under construction and will be based on some feedback from others to help build the section out.
|
||||
Reference in New Issue
Block a user