In my last blog post, I introduced you to the solution I’m using on Office 365 to create personal e-mail addresses. This solution is hosted on Azure DevOps and is automatically released to the PowerShell Gallery. In this blog post, I will explain briefly how this works.
A secure email system is important to protect yourself from the increasing phishing and spam attacks, where hackers try to steal money on a large scale. More and more organizations hosting personal data are getting hacked, where hackers misuse this personal data to launch attacks. In this blog post I will introduce you to a solution I’ve created based on Office 365 and PowerShell to prevent that my email address is spread more widely on the internet.
Microsoft recently announced the Public Preview of the ability to run PowerShell code in an Azure Function. This means that the PowerShell code will run in a Platform-as-a-Service solution, completely serverless! You pay only for the time that you use the solution and you don’t have to manage the underlying infrastructure! In this blog post, I will show a practical example of how to use an Azure Function in combination with an Azure Logic App.
Because of the recent domain change of my blog, I decided to completely start over again with my lab in Azure. I’ve been working with Desired State Configuration Configs in Azure for quite a few years, but never used them for my own lab environment. It felt a bit overkill to do that, but now I wanted to start over and do everything right.
This step-by-step installation guide explains how to create a DSC Configuration in Azure Automation and how to apply this on your domain controller in Azure.
With Windows 10 1607, Microsoft introduced Dual Scan functionality, which allows the computer to connect with Microsoft Updates besides using WSUS or SCCM. Steve Henry from Microsoft: “It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides all other content.” I’ve seen various blog posts not covering all the steps I had to take to ensure Windows only looks to SCCM/WSUS. Especially covering Windows 10 deployments with System Center – Configuration Manager.
So you are signing your PowerShell scripts as a Best Practice from Microsoft. Good job! You’ve configured the PowerShell Execution Policy as AllSigned and you’ve created an application in SCCM where you run the signed script as:
PowerShell.exe -File .\Script.ps1
The application installs just fine on your machine from the Software Center. During the Task Sequence, the application cannot be installed and in the Event Viewer. You’ll find the following error message:
PowerShell.exe: File <Filename> cannot be loaded because running scripts is disabled on this system. For more information, see about_execution_policies at…”
You open up PowerShell to see the current ExecutionPolicy. “Get-ExecutionPolicy -List” shows that all scopes have undefined execution policies. With “Get-Help about_Execution_Policies” you find out that Undefined policy is equal to a restricted policy and that “Permits individual commands, but will not run scripts”.
Go back to your application in SCCM and make sure you set the ExecutionPolicy to AllSigned so it will work both during a Task Sequence and while working in OS.
PowerShell.exe -ExecutionPolicy AllSigned -File .\Script.ps1
# Variables $InternalSwitchName = "Internal Virtual Switch" $NATGatewayPrefixLength = "24" $NATGatewayNetwork = "192.168.0.0/$NATGatewayPrefixLength" $NATGatewayIP = "192.168.0.1" $NATNetworkName = "NAT Network" # Create the VM Switch and NAT Gateway New-VMSwitch -SwitchName $InternalSwitchName -SwitchType Internal New-NetIPAddress -IPAddress $NATGatewayIP -PrefixLength $NATGatewayPrefixLength -InterfaceIndex (Get-NetAdapter -Name $("vEthernet ($InternalSwitchName)")).InterfaceIndex New-NetNat -Name $NATNetworkName -InternalIPInterfaceAddressPrefix $NATGatewayNetwork