OWA and ECP failure after Install Exchange 2016 CU17

I recently ran into an issue after update Exchange 2016 from CU15 to CU17. The upgrade installation took around an hour, but was eventually completed successfully according to the Installation Wizard at least. When I tried to access ECP, I got the error below even before the login page shows up. At the meantime, Exchange Management Shell is inaccessible due to the error. In the eventlog, there are lots of 1003 errors relate to MSExchange Front End HTTP Proxy.  After some research, it appears the issue is caused by corrupted SharedWebConfig.config files in C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy and C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess. But regenerating the files base on this MS document didn't fix the issue. I end up had to setup a test Exchange 2016 CU17 in my own lab environment. Once the new Exchange is up, I copied those 2 SharedWebConfig.config files to the production Exchange server and then did a IISRESET. To my dismay, ECP t

Package and deploy a PowerShell Lambda function with custom modules

Recently I had the need to create a Lambda function with PowerShell 7. The function is to synchronize data between two REST APIs. It's fairly simple, but does need to use a custom made module. I spent quite bit time to find out how to deploy PowerShell Lambdas with custom modules. Thought might write a guide to help people want to do the same.    My script is fairly simple, it get a list of users from one API and then convert it to a XML format object and export into the target API. To reuse some of the code, The script requires AWS.Tools module as well as a custom made module, let's called it CAT. The CAT is module contians some functions that are invoked in by the main script. The inital lines of my main script looks like below: #Requires -Modules @{ModuleName='AWS.Tools.Common';ModuleVersion=''} #Requires -Modules @{ModuleName='AWS.Tools.SecretsManager';ModuleVersion=''} #Requires -Modules CAT  In addition to install the AWS.Tool

Test out PowerShell 7 new features in WSL

Finally, PowerShell 7 is now GA! As a heavy WSL user, I was keen to see how some of its new features will work in WSL1 (Ubuntu 4.4.0-18362-Microsoft). Below are the tests I have done. Installation in WSL Download the binary from Github repo to a local folder /usr/share/powershell sudo wget Untar the file sudo tar xzvf powershell-7.0.0-linux-x64.tar.gz Add path for your shell export PATH=/usr/share/PowerShell:$PATH Reload .bashrc source .bashrc Remove the tar ball sudo rm /usr/share/PowerShell/powershell-7.0.0-linux-x64.tar.gz Run PowerShell 7 by run pwsh Import Windows Modules in WSL Install commonly Vendor released modules like VMware PowerCli Install-Module -Name VMware.PowerCli Install .Net based modules also works fine. Install-Package PrtgApi What about those module require Windows GUI, like Out-GridView? PowerShell 7 on Windows fully support this

Monitor AWS VPC Connectivity with Python

We recently have the need to cutover our AWS Direct Connects to a different vendor. In order to carry out the change, I was tasked to find a way to monitor Direct Connect connectivities to our on premise network from our hundreds of VPCs in AWS. After some discussion with our network engineers and security team, the solution I end up using is to deploy a single EC2 instance into each those VPCs that has a connection to VGW. We then add those instance IPs into PRTG to monitor with Ping and Http sensors. To allow the instance to be deployed into the targeted AWS accounts, we use CloudFormation StackSet to push out a role into each of those accounts first. The role then allows the "Master Account" to have permission to create and update necessary resources within the target accounts. The instance uses a t3.nano tier alogn with Amazon hvm Linux2 AMI (Use our own hardened AMI in my case). A simple Nginx test page is installed on the instance to allow us to monitor TCP traf

RDP to EC2 with SSM Port Forwarding

Say you have a bunch of Windows servers hosted in AWS. The VPC they are in does not have VPN or Direct Connect connect back to your on premse network. Expose RDP port through public IP for these Windows servers is a very good way to get hacked. So how can we securely connect to the servers in this kind setup? Fortunately we have SSM for the rescue. In August, AWS announced a new feature for SSM Session Manager, which allows us to securely create tunnels between your EC2 instances deployed in private subnets and your local machine. You can read about the announcement here . Here are the steps you can setup for Windows Instances. 1. Configure the Windows EC2 as Managed Instances in SSM. This mainly involves assign a IAM EC2 Role to the instance with SSM policies. Since the focus of this post is about Session Manager Port Forwarding, I won't expand this too much. you can find more details about initial setup of SSM  here . 2. For your existing Windows EC2s, you will need to up

VMware Site Recovery Manager Multi-Site Pair Deployment

I was recently involved in a data center migration project, which used VMware SRM (Site Recovery Manager) as the migration tool to move virtual machines between 3 DCs. The diagram below shows how the setup looks like. The version of SRM is 8.1. [SiteA] <----> [SiteB] <----> [SiteC] VMware documentation refer the above scenario as Shared Recovery Site. For each site-pair, you will need to deploy individual SRM server to ensure the SRM Plug-in ID is unique to that pair. So in our case, SiteB-C pair requires a new SRM server in Site B and Site C. Install SRM The steps below shows the configuration details of the installation process on each SRM server. 1. Provide the PSC server details of the site 2. Provide the vCenter server details of the site 3. Provide the local SRM extension details 4. This is the most important part of the configuration. Make sure you choose Custom Site Recovery Manager Plug-in Identifier . The Plug-in ID needs to be the same on both Site

How Secure is RDP?

Hands up if you have following setup/practices in your organization: A RDP server (Terminal server) that everyone can jump onto. Apart from the IT admins, some users have local admin rights on the box, just so they can run or configure a particular application. To help troubleshooting an issue, your IT admins often RDP to servers directly from user's laptop, which the user is a local admin. A group of users have local admin rights on a particular Windows box, and your Domain Admins also need to RDP to from time to time. If any of above scenario applies to your organization, you might want to consider introducing some changes. This is why: It is well known that Windows Remote Desktop Service has this feature that allows you to connect to another user's session. But obviously you will need to know the other user's credential to do that, right? No, not necessarily. With NT AUTHORITY/SYSTEM account, you can hijack the user's RDP session without the nee