#Windows #Azure #AVD

Recently, a company I work with requested a way for users to access a web app that they were hosting on-premises, but didn't want to open up connections to the app to the internet. The app is out of support from the vendor and can't be opened outside of their secure network.

We planned to allow access to the app by instructing users to connect over a VPN, but we found this would be a hassle for users, as they would need to install the VPN client, connect to the VPN, and then launch a browser to access the app. In this case, the site also requires IE11 with a custom extension to be installed. These requirements just to access a single site really made it a headache for users and the Helpdesk received regular tickets from staff who had issues accessing the site.

Instead of the VPN approach, we deployed a Microsoft Edge shortcut in Azure Virtual Desktop. This approach has advantages because it allows users to launch a browser window and jump onto the network that the Host Pool is connected to. If you have your networking configured correctly in Azure, you can access internal sites and apps without going over the internet directly from the client PC. This also allows you to control the browser version and other settings that are configured in the Host Pool. If paired with Intune policies, you can define the browser settings and extensions that are available to users and require certain sites to open in Internet Explorer Compatibility Mode. This could be helpful if you have a legacy app that only works in IE11 and requires a specific extension to be installed.

In this post, I'll show you how to deploy a Microsoft Edge shortcut in Azure Virtual Desktop.

To start, you must have an existing Azure Virtual Desktop deployment set up with Host Pools and a Workspace. You'll also need at least Contributor access to the Resource Group you're working in.

Create a new Application Group in Azure Virtual Desktop.

On the Basics tab, make the following changes:

• Subscription and Resource group – Set for your AVD environment.
• Host Pool – Select the Host Pool you want to deploy the shortcut to.
• Application group type – Remote App (RAIL)
• Application Group name – Something like BrowserShortcuts

On the Applications tab, click the “Add applications” button and set the following properties:

• Application source: File path
• Application path: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
• Application name: Your shortcut name
• Display name: Your shortcut name
• Icon path: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
• Icon index: 0
• Description:
• Require command line: Yes
• Command line: http://google.com/

If you want multiple tabs to open, separate the URLs with a space. For example, http://google.com/ http://bing.com/

On the Assignments tab, select your user or group:

On the Workspace tab, change the “Register application group” to “Yes” and you should already have an application group assigned.

You can leave the Advanced and Tags tabs as default.

After saving the Application Group, you should see the shortcut in the Azure Virtual Desktop client in a few minutes. You may need to click the Refresh button to force it to update:

These steps allow you to deploy secure web apps inside your AVD deployment. Whether you're connecting to a legacy web app that you're hosting on prem or you have specific application or environment requirements that you need to meet, this is a great way to provide access to your users without having to jump through hoops.

If you combine this Edge shortcut with Intune policies that require Edge to open certain sites in Internet Explorer Compatibility Mode, you can ensure your users can easily access apps and sites quickly without compromising your secure internal network.

Discuss...

#Windows #Azure #AVD #Intune

I recently had an issue with an Azure AD Joined host pool in Azure Virtual Desktop where users could not successfully login using their Azure AD credentials.

In our environment, both the client computer and the Azure Virtual Desktop host computer are Azure AD Joined. The user was able to log in to their Azure AD Joined computer, but when they tried to log in to the Azure Virtual Desktop host computer, they would get an error message:

Couldn't connect. Something went wrong when we tried to connect. If this keeps happening, ask your admin or tech support for help. Error code: 0x9735 Extended error code: 0x0 Activity ID: {e194ae11-b2ed-4d33-9520-c1d5ed140000}

The error message the users received came after a loop of unsuccessful logins using a combo of azuread\user or user@domain.com that would say “Establishing Connection”, “Configuring Gateway”, “Securing connection to remote PC” and then fail with the following error: “The username and password used to connect to the remote resource didn't work. Enter a different account and try again.”

As a note: Connections to Host Pools in a different AVD environment that are joined to Active Directory work fine. The issue seems to occur when the client computer and the AVD host computer are Azure AD Joined.

Currently, as of February 2023, the official Microsoft package for the Remote Desktop app in the Microsoft Store installs an old version of 10.2.3000.0 that has bugs connecting to Azure AD Joined Azure Virtual Desktop Host Pools. This buggy version impacted our organization because we deploy the Microsoft Remote Desktop app using an Application Deployment in Intune. We've tested this issue using the Microsoft Store for Business, Microsoft Store (Legacy), and the new Microsoft Store (WinGet) deployments and all of them have the same issue and run the same version:

The workaround for this error is to uninstall the Microsoft Store version of the application and install the latest version of the Remote Desktop app from the Microsoft website at this link: https://learn.microsoft.com/en-us/azure/virtual-desktop/whats-new-client-windows

I manually installed Public Release version 1.2.3918.0 and it fixed my connectivity issues. To get this rolled out to your Intune devices, you will need to package the MSI file from the Microsoft website and deploy it using an Application Deployment in Intune.

I hope this helps someone else who is having this issue. Microsoft should really update the Microsoft Store version of the Remote Desktop app to the latest version to avoid this issue.

References

• https://www.anoopcnair.com/avd-azure-ad-joined-vm-login-issue-error-0x9735/
• https://learn.microsoft.com/en-us/azure/virtual-desktop/users/connect-windows

Discuss...

#Azure

After setting up RedCap in Azure in a previous post, I got a request to add an external person to your RedCap installation. I wanted to document what I did to make it easier for others.

To make user management easier, I created an Assigned Security Group in Azure AD titled “RedCap Users”. I then added the Group assignment to the RedCap app in Azure AD at Enterprise applications > RedCap > Users and groups > Add user/group:

After I assigned the Group to the app, I invited my external Gmail account to the Azure AD tenant at Users > New user > Invite external user:

I added my user information, then added the account to the RedCap users group:

After I added the account, I needed to change the setting in Azure AD to allow external Microsoft accounts to access Redcap. To do this, I needed to change the App Registration Manifest, found in Azure AD > App registrations > RedCap > Manifest.

I changed 2 values from the default:

• "accessTokenAcceptedVersion": Null, ↪ "accessTokenAcceptedVersion": 2,
• "signInAudience": "AzureADMyOrg", ↪ "signInAudience": "AzureADandPersonalMicrosoftAccount",

After making these changes, I checked my email and completed the invitation to the Azure AD tenant:

After going through the signup process, I see the App listed in the My Apps page for my Guest account:

After clicking through, I was able to setup my RedCap account and was authorized to login:

My RedCap user account shows up as my email at tdannecy_gmail.com#ext#@DOMAIN.onmicrosoft.com, indicating that I am a Guest/External account in the tenant:

When I login as a RedCap administrator, I can see my Guest account has been added to the Browse Users list:

I hope this was helpful to others. It took me a bit to find the attribute I needed to change in the Manifest to get it working.

Discuss...

#Azure

I recently got a trial of Lucidscale, a tool that can ingest your Azure environment and automatically create a resource visualization diagram.

I am pretty happy with the product and will recommend that my company purchase it for client work.

I wanted to detail the setup process in Azure so it's easy to use.

To get Lucidscale to interact with your Azure subscription, you will need to be a Global Administrator. To try Lucidscale, you will need a trial. Once you get that setup, you can continue to configure it.

First, navigate to the main Lucid website and click New > Lucidscale > Azure Model:

We will need to configure the subscription information to connect into Azure. Click “Open Data hub to Import Subscriptions”:

Click “New Subscription”:

You can automate using an Azure CLI script, but for now let's set it up manually. Click “Azure AD Application”:

Now, we are ready to configure your Azure environment to allow access to the tool. Open a new tab and navigate to Azure Active Directory. Click “App registrations” and then click “New registration”

Inside the wizard, type the name you want to use and then click “Register”. Leave the other options on the default setting:

After registering the app, open the configuration settings inside Azure AD. Navigate to the “Overview” blade and copy and paste the Application (client) ID and Directory (tenant) ID over into the Lucidscale setup page:

After pasting in that info, navigate to the “Certificates & secrets” blade in Azure AD and click the “Client secrets” tab. Click “New client secret”. Fill in a name and click “Add”:

Once you've created the secret, copy and paste the “Value” of the client secret from the Azure AD page into the “Client Secret” box in Lucid:

After pasting in the three required values, enter an Application name in Lucid. I named mine after the client company.

Now, we will need to give permissions to the App Registration so that it can read the Azure environment. Navigate to the Subscription blade in Azure and click on the one you want to use. Click on the “Access control (IAM)” blade, then click “Add > Add custom role”:

On the “Basics” tab, type a Custom role name. I used “Lucidscale import”. Under “Baseline permissions”, select “Start from JSON” and upload the following file:

{
    "properties": {
        "roleName": "Lucidscale import",
        "description": "Role that gives Lucidscale read access to import resources",
        "assignableScopes": [],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Authorization/roleAssignments/read",
                    "Microsoft.ApiManagement/service/read",
                    "Microsoft.Compute/disks/read",
                    "Microsoft.Compute/virtualMachines/read",
                    "Microsoft.Compute/virtualMachineScaleSets/read",
                    "Microsoft.Databricks/workspaces/read",
                    "Microsoft.DBforMySQL/servers/databases/read",
                    "Microsoft.DBforMySQL/servers/read",
                    "Microsoft.DBforPostgreSQL/servers/databases/read",
                    "Microsoft.DBforPostgreSQL/servers/read",
                    "Microsoft.DocumentDB/databaseAccounts/read",
                    "Microsoft.KeyVault/vaults/read",
                    "Microsoft.Network/applicationGateways/read",
                    "Microsoft.Network/azurefirewalls/read",
                    "Microsoft.Network/connections/read",
                    "Microsoft.Network/dnszones/read",
                    "Microsoft.Network/dnszones/recordsets/read",
                    "Microsoft.Network/frontDoors/read",
                    "Microsoft.Network/loadBalancers/read",
                    "Microsoft.Network/localnetworkgateways/read",
                    "Microsoft.Network/networkInterfaces/read",
                    "Microsoft.Network/networkSecurityGroups/read",
                    "Microsoft.Network/privateDnsZones/read",
                    "Microsoft.Network/privateDnsZones/ALL/read",
                    "Microsoft.Network/privateDnsZones/virtualNetworkLinks/read",
                    "Microsoft.Network/privateEndpoints/read",
                    "Microsoft.Network/publicIPAddresses/read",
                    "Microsoft.Network/routeTables/read",
                    "Microsoft.Network/trafficManagerProfiles/read",
                    "Microsoft.Network/virtualNetworkGateways/read",
                    "Microsoft.Network/virtualNetworks/read",
                    "Microsoft.Network/virtualNetworks/subnets/read",
                    "Microsoft.Resources/subscriptions/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.ServiceBus/namespaces/read",
                    "Microsoft.ServiceBus/namespaces/queues/read",
                    "Microsoft.Sql/servers/databases/read",
                    "Microsoft.Sql/servers/read",
                    "Microsoft.Storage/storageAccounts/read",
                    "Microsoft.Web/serverfarms/Read",
                    "microsoft.web/sites/functions/read",
                    "Microsoft.Web/sites/Read"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Navigate to the Permissions tab. The JSON is not complete and you will need to add an additional role to this list. Click the “Add permissions” button, then search for “managed”. Check the box for Microsoft.ManagedIdentity/userAssignedIdentities > Read : Get User Assigned Identity. Click the “Add” button when you're finished.

Navigate to the “Assignable scopes” tab and click the “Add assignable scopes” button. Change the Type field to “Subscription”, then click on your subscription in the right column. Click “Select” when you're finished:

Leave the JSON tab as default and complete the wizard to Create the role.

Once you've created the role, return to Azure Active Directory and open Subscriptions. Select the subscription you want to use.

Navigate to the “Access control (IAM)” blade and navigate to the “Roles” tab. Search for “Lucid” and locate your newly created role. Click the “View” link:

In the new popup, click on the Assignments tab, then click “Add assignment”:

Navigate to the “Members” tab. Check the radio button for “Assign access to” as “User, group, or service principal” and click the “Select members” button. Search for “Lucid” in the popup window and click on your app. Click the “Select” button when you're finished:

After you've completed this part, complete the wizard to add the role assignment in Azure AD.

Now that we've configured the environment, return to Lucidscale to complete the configuration. Move to the “Select Subscriptions” page and check the box next to the correct subscription:

On the “Subscription configuration” tab, leave all options as default and click the “Import Azure subscriptions” button:

After completing the wizard, data import will begin. This process could take a while, depending on the size of your environment.

When it's complete, select your subscription and click the “Create new Model” button:

Check the box next to the subscription you want to diagram, then click the “Choose subscriptions” button at the bottom right.

Review your selection and then click “Create Azure Model”.

Now, Lucidscale will build your model in the background. It could take a while, depending on the size of your environment:

After it's complete, your diagram will be generated:

Discuss...

#Azure #PowerShell #Windows

If you’ve added a new session host to an existing Azure Virtual Desktop host pool, you might get a Windows Activation error watermark notifying you that the Windows license wasn’t found:

Activate Windows. Go to Settings to activate Windows.

When I got the ticket from users complaining about the watermark, I started brainstorming. I thought I might be able to fix this issue several ways:

1. License users with Microsoft 365 E5.

2. Manually add an existing Windows license (only possible if you’re running a stock image of Windows, not the Azure-specific Windows Enterprise Multi-Session).

Since I don’t have those E5 licenses already and I’m running the multi-session OS, it would add cost to purchase and I would need to get approval.

Instead, I found that you can check the VM license by running this command in PowerShell (change the XXX values to match your Resource Group and VM name):

Import-Module AzCLI 
Connect-AzAccount
Get-AzVM -ResourceGroupName XXXresourcegroupXXX -Name XXXvirtualmachineXXX

After running that command, the string that you want to focus on is LicenseType. If it says Windows_Client, you are good to go and Azure will apply the license on the OS-level.

If it is null or displays as {}, that could be a cause for the Activation error. You can run this PowerShell command in the AzCLI (edit the XXX values to match your environment):

$rg = XXXresourcegroupXXX
$vm = XXXvirtualmachineXXX
$vm.LicenseType = ‘Windows_Client’

Get-AzVM -ResourceGroupName $rg -Name $vm | Update-AzVM 

I wish Azure had a built in Troubleshooting function or feature to “quick fix” this issue, but I couldn’t find one.

Putting this here for my notes when I have to fix this issue again.

Discuss...

#Azure #Exchange

A company I work with requested a deployment of RedCap, a web application for building and managing online surveys and databases, into their Azure environment.

Currently, the official RedCap documentation is incomplete and has inaccurate instructions on some of the Azure steps.

While I got this rolled out for the company, I decided to take detailed notes to help others in deploying this in Azure. This process is detailing my environment, running REDCap 12.5.4, PHP 7.4.28 (Windows OS), MySQL 5.7.32

Deployment

To start, you'll need the following credentials:

• Global Administrator access to your Azure tenant or the ability to create AppService Plans and roll out Templates
• Exchange Administrator
• Admin access to your public DNS provider
• RedCap Community site access

Begin by opening your browser and navigating to the official RedCap GitHub fork for the Azure Template: https://github.com/vanderbilt-redcap/redcap-azure

Click on the link in the README page with the text “Deploy with your SMTP Relay” to open the Azure Template page and begin deployment:

• Subscription: Choose your organization's subscription
• Resource group: Create new to keep things organized
• Region: Choose the region closest to the usage location
• Site Name: Something with “Redcap” to keep it organized
• Administrator Login: Keep the default of redcap_app
• Administrator Login Password: Set to a strong password
• Redcap Community Username and Password: Copy and paste this from your welcome email from RedCap after purchasing a license. If this information is not correct, the Template deployment will fail because it won't be able to download the RedCap installation.
• Redcap App Zip Version: latest
• From Email Address: Create an Shared Mailbox in Exchange and put it here like redcap@domain.com. Login to the Microsoft Admin center and reset the password for that RedCap Shared Mailbox as a User object.
• Smtp FQDN: smtp.office365.com
• Smtp User and password: redcap@domain.com
• Smtp Port: 587
• Sku Name: S1
• Sku Capacity: 1
• Database Sku Size MB: 5120
• Database For My Sql Tier: General Purpose
• Database For My Sql Family: Gen5
• Database For My Sql Cores: 2
• Mysql Version: 5.7
• Storage Type: Standard_LRS
• Storage Container Name: redcap
• Repo URL: https://github.com/vanderbilt-redcap/redcap-azure.git
• Branch: master

You can adjust the size of your AppService after deployment, so leave the Sku options default.

After inputting your data, deploy it and wait about 30 minutes for everything to provision and install.

I had some issues with the deployment, specifically the clean up tasks at the end. These can be ignored. You should have a working install if the following items were created successfully:

• AppService Plan
• AppService
• Azure Database for MySQL single server
• Storage Account

After deploying, there are quite a few things you'll need to fix before rollout.

You should be able to open the newly deployed RedCap app in the Azure Portal by navigating to your Resource Group and clicking on the RedCap AppService. On the Overview blade, click on the “Browse” button:

You should be able to open the app with no authentication.

Click on the Control Center button at the top of the page and click on Configuration Check on the left pane to begin working through the many issues displayed on this page.

Fixing cron process

For some reason, the scheduled tasks performed by the cron process are not running as expected after deployment. This impacts regular server tasks like database cleanup and sending emails.

To work around this issue, you'll need to create a manual job in the App Service that forces the process to start. This manual job has two files: a PowerShell script that calls PHP and cron, and a cron file that sets a schedule for auto-running the app every minute. Since RedCap was created using an Azure Template, we won't be able to use the built in portal GUI since Azure wants to keep the git repository in sync that we used in the Template. We will need to create this process manually, but the task is configurable inside the Azure Portal after creation.

To start, open the Azure App Service page for your newly deployed app and navigate to the “Advanced Tools” blade. This opens a tool called Kudu.

From the Kudu dashboard, navigate to Debug console > PowerShell.

In this browser, navigate to /site/wwwroot and click on the Plus icon and select “New folder”.

Create all folders until you have the following structure: C:\home\site\wwwroot\App_Data\jobs\triggered\Start-CronService

Create a file in that location and name it Start-CronService.ps1. Click on the pencil/edit icon and paste in the following PowerShell command:

# Start-CronService.ps1
# Tim D'Annecy - 2022-08-04
# Starts the cron PHP service
# Should be deployed to C:\home\site\wwwroot\App_Data\jobs\triggered\Start-CronService\Start-CronService.ps1
# Had to hard code URIs for some reason... Working with RedCap 12.5.1

function Start-CronService {
    $cronFile = 'C:\home\site\wwwroot\cron.php'
    $phpExe = 'C:\Program Files (x86)\PHP\v7.4\php.exe'

    Start-Process -NoNewWindow -FilePath $phpExe -ArgumentList $cronFile
}
Start-CronService

In that same folder, create a file titled settings.job and paste in the following code:

{
  "schedule": "0 */1 * * * *",
}

After creating these files, you should have the following items in your folder at C:\home\site\wwwroot\App_Data\jobs\triggered\Start-CronService:

After saving, restart your AppService from the “Overview” blade. You will see this task appear from the AppService page under the WebJobs blade:

You can check the status by viewing logs logs and stop/start the process, as needed.

Subdomain and HTTPS connection

At this point, your app is reachable over HTTP with the long name of blah.azurewebsites.com. It's better to use a subdomain like redcap.domain.com and to force users to access the site over HTTPS.

To accomplish both of these, you'll need to make a few changes in your DNS hosting provider, in the Azure environment, and inside the RedCap AppService.

To begin, navigate to the Azure Portal and open up your AppService for RedCap. Click on the “Custom domains” blade and change HTTPS Only to On. After this is enabled, you can add your custom subdomain.

Click the “Add custom domain” button and fill in the subdomain that you want to use. For this example, I'm using redcap.domain.com

After opening the “Add custom domain” configuration pane, open a tab for your DNS provider. The company I'm working with uses Oracle DynDNS.

From the custom domain configuration pane in Azure, you'll copy and paste the following values into your DNS provider:

1. From “Custom Domain Verification ID” in Azure into a TXT record in DNS for asuid.redcap.domain.com.
2. From CNAME in Azure into a CNAME record in DNS for redcap.domain.com

Once these are in place, you'll create a certificate in Azure to secure the web connection for HTTPS traffic.

Open the “Certificates (preview)” blade. Click “Add certificate”. Set the Source to “Create App Service Managed Certificate” and type in your subdomain from earlier (redcap.domain.com). The “Certificate friendly name” can be set to something more readable, if you like. Change the SSL binding to a “SNI SSL” and deploy it:

Once this certificate is deployed, switch back to the “Custom Domains” blade. You should see your subdomain populated as “Secure”. You should be able to load your site over an HTTPS connection and your certificate will be valid. You may need to wait a little bit for DNS and the certificate to propogate.

After making this change in Azure, navigate back to your RedCap instance and open Control Center > General Configuration and change the “REDCap base URL” to your subdomain (e.g. https://redcap.domain.com).

Azure AD single-sign on

This piece is very finicky. If you make an error in setting the SSO settings inside Redcap, you can get locked out of your instance. If this happens, you can use a SQL query on your to get back in:

UPDATE `redcap_config` SET `value`='none' WHERE `field_name`='auth_meth_global' LIMIT 1

Navigate back to your AppService for RedCap and click on the “Authentication” blade. Click “Add an identity provider”.

In the wizard, on the Basics tab, change the Identity Provider to Microsoft and change the “App registration type” to Create new app registration. Give it a name like “RedCap”. Change the “Supported account types” to Any Azure AD directory - Multi-tenant. Leave the other fields as default.

On the Permissions tab, keep the default value for User.Read:

After adding the identity provider, return to the Authentication page. Click on the Pencil icon next to your new Authentication provider.

On the “Edit identity provider” page, copy the Application (client) ID.

Open your RedCap instance and navigate to Control Center > Security & Authentication and change the “Authentication Method” to Azure AD OAuth2. Scroll down the page and paste this Application ID into the “Azure AD API Client ID” field:

Click on Client secret value. It will redirect you to the AppService Configuration blade. Copy the value of the MICROSOFT_PROVIDER_AUTHENTICATION_SECRET into the RedCap field for Azure AD API Client Secret:

Set your RedCap@domain.com account or yourself as a Primary and/or Secondary Admin and click “Save”.

You might need to save this value twice, RedCap may reload the page without saving the values. After saving, you will need to set some values in Azure AD to handle post-login behavior.

Navigate to the Azure AD portal

Navigate to the “App registrations” blade and click on the RedCap application you named earlier. Open the “Authentication” blade.

Under the “Web” section, you'll need to add the following two URLs to your instance for the URL callback: * https://redcap.domain.com/.auth/login/aad/callback * https://redcapFULLNAME.azurewebsites.net/.auth/login/aad/callback

Under “Select the tokens you would like...” to be set to ID tokens (used for implicit and hybrid flows)

After that, navigate to the “API permissions” blade and click “Add a permission”. Select Microsoft Graph > Delegated permissions. Add the following items and save :

• OpenID permissions
  • email – View users' email address
  • openid – Sign users in
  • profile – View users' basic profile
  • User.Read – Sign in and read user profile

After making these changes, try accessing your domain at https://redcap.domain.com.

If you can successfully login, you'll get this error on the page Control Center > Configuration Check:

“siteadmin” user should not be an Administrator! It appears that the user “siteadmin” is an Administrator. However, this user account should ONLY ever be an Administrator when the system-level authentication method is set to None (Public), otherwise this user should NOT be an Administrator. You should go to the “Administrators & Acct Managers' page and remove them as an Administrator immediately, otherwise users accessing public REDCap projects may gain access to things that only REDCap Administrators should be accessing.

The instructions in this error are not accurate to the current version of RedCap. To make this error disappear, navigate to the Control Center > Administrator Privileges and uncheck all of the permissions for the user:

After that's cleaned up, you can suspend the account on the Control Center > Browse Users > View list by criteria page. Click the “Display user list” button and select the site_admin account. Check the box next to the account and suspend it using the button on the bottom:

Do not delete this user. On a reboot of the AppService, RedCap will check to make sure this user is still present and show a database error if it's missing.

Cleaning up

After you've made these changes, you can delete some items out of the Configuration page in the AppService blade, as recommended by RedCap documentation, but there's no real reason to do so.

MySQL database changes

RedCap will give you a warning about the default MySQL database configuration:

Your database configuration settings do not appear to be optimal. For better database performance and stability, consider making the changes below to your database configuration settings in your my.cnf (Linux/Unix) or my.ini (Windows) configuration file. TIP: Remember to restart the MySQL service after making any edits to the configuration, otherwise they won't take effect.

Navigate to the Azure Portal and open up the SQL object that was created with the Template deployment. Navigate to the Query Performance Insight blade. From here, click on the top banner:

Change the following options and save: * query_store_capture_mode = ALL * query_store_capture_utility_queries = YES

Over time, Azure should make recommendations to adjust your SQL configuration to be more efficient.

User-uploaded document store

After first install and logging in with an admin account, RedCap will give an error about the user-uploaded documents:

Directory that stores user-uploaded documents is exposed to the web: It is HIGHLY recommended that you change your location where user-uploaded files are stored. Currently, they are being stored in REDCap's “edocs” directory, which is the default location and is completely accessible to the web. Although it is extremely unlikely that anyone could successfully retrieve a file from that location on the server via the web, it is still a potential security risk, especially if the documents contain sensitive information. It is recommend that you go to the File Upload Settings page in the Control Center and set a new path for your user-uploaded documents (i.e. “Enable alternate internal storage of uploaded files rather than default 'edocs' folder”), and set it to a path on your web server that is NOT accessible from the web. Once you have changed that value, go to the 'edocs' directory and copy all existing files in that folder to the new location you just set.

You can fix this by navigating to the Control Center and opening the “File Upload Settings” page. From here, change the dropdown to Microsoft Azure Blob Storage and scroll down to the section with the same title.

Open another browser tab and navigate back to your Resource Group that you setup in Azure. Open the Storage account for the app and copy and paste the Storage account name and the blob container name:

In the Azure tab, open the Access keys blade and copy and paste the Key from Key1 in the RedCap configuration page:

Save the changes at the bottom of the page, then confirm this worked by opening the Control Center and clicking on Configuration Check.

SMTP settings

The company I'm working with is using Exchange Online for its email service. To make things easy with Redcap, I created a Shared Mailbox of “RedCap@domain.com” and set a password on the Microsoft 365 Admin dashboard.

After a fresh install of RedCap 12.5.4, the SMTP settings I set in the Template did not work:

REDCap is not able to send emails – CRITICAL: It appears that your SMTP configuration (email-sending functionality) is either not set up or not configured correctly on the web server. It is HIGHLY recommended that you configure your email/SMTP server correctly in your web server's PHP.INI configuration file or else emails will not be able to be sent out from REDCap. REDCap requires email-sending capabilities for many vital application functions. For more details on configuring email-sending capabilities on your web server, visit PHP's mail configuration page.

To fix this, you'll need to open Control Center > General Settings. Scroll down to the “Configuration for Outgoing Emails” section and set the Universal FROM Email address as your redcap@domain.com email. Also set this same email under Other system settings under Email Address of REDCap Administrator.

After you update the config, you'll also need to update the version of SendMail. The one bundled with RedCap 12.5.4 does not work with TLS 1.2 and needs to be updated. To do this, we'll push the files to the AppService using FTPS.

Start by opening the GitHub page for Sendmail with TLS 1.2: https://github.com/sendmail-tls1-2/main . Download the Sendmail_v33_TLS1_2.zip file and unzip the files on your computer.

Edit the file settings.ini and put in the SMTP settings you set earlier during the deployment step, be sure to change these values to your environment:

• smtp_server=smtp.office365.com
• smtp_port=587
• smtp_ssl=auto
• auth_username=redcap@domain.com
• auth_password=XXX
• force_sender=redcap@domain.com
• hostname=domain.dom

After making the changes to the file, save and close it. Now, you'll upload the patched Sendmail with the changed .ini file into your AppService using FTPS.

Navigate to the Azure Portal and open your RedCap AppService. Click on the “Deployment center” blade. Click on the “FTPS credentials” tab.

Download FileZilla or another application that can connect to an SFTP endpoint. For this example, I'll be using FileZilla.

Open the app and add a new site. Copy the connection information from the AppService FTPS credentials page into FileZilla:

Once you've connected to the FTPS endpoint, use the left pane to find the new Sendmail folder that you unzipped on your local computer. Navigate on the right pane to the location C:\home\site\repository\Files\sendmail. Select and right click on all of the files in the Sendmail folder in the local view and click “Upload”, overwriting all files.

After this is complete, restart your AppService for the patched changes to take effect.

If your organization is using Azure AD's Security Defaults, you will need to allow the redcap@domain.com account to use basic authentication to login.

To do this, open Azure AD Conditional Access policies and allow basic authentication for your redcap@domain.com account, or add an exception:

You will also need to create a Rule inside Exchange Online to allow emails to go through without being tagged as Spam. To do this, open the Exchange Admin center and navigate to Mail flow > Rules. Create a new rule with the following properties:

• Name: Allow RedCap emails
• If the message... Includes these words in the sender's address: 'redcap'
• Do the following... Set the spam confidence level (SCL) to '-1'
• Rule mode Enforce
• Additional properties Sender address matches: Header

You can send a test email inside RedCap by navigating to Control Center > Email Users.

You can get logs from email delivery issues by opening the directory C:\home\site\repository\Files\sendmail inside the Kudu, or Advanced Tools, from your AppService page. The debug.log file should have any applicable email failures.

If emails are still not sending, check to make sure that the cron job is running with the WebJobs blade in your AppService.

Conclusion and caveats

After deployment and performing these cleanup tasks, you should have a fully working environment for a Microsoft shop: hosted in Azure, uses AzureAD for authentication, and Exchange Online for SMTP.

Since the official RedCap Azure template does not currently have support for automatic updating, you'll need to redeploy it each time. I haven't tried redeploying yet, but I'll make a new post when a major new version comes up.

Overall, this process has been difficult because the RedCap documentation is currently not updated and is often incomplete. Hopefully this guide can help someone else get the system online with modern hosting and authentication without headaches.

Discuss...

#Windows #Powershell #Azure

I have a few companies that I work with that are using a traditional Active Directory domain environment (GPO, WSUS, etc.) but are not using an inventory tool like Intune or PDQ.

One of the biggest issues that they report is that they aren't able to get any information about live machines in their environment.

Gathering this information is a critical step in moving to cloud-based endpoint management. You won't be able to decommission a domain if there are objects that still check back in to on-prem infrastructure for management.

To work around this, I wrote a Powershell script that runs on a local computer, gathers some information about its config, then pushes it to an Azure Table. This collected data can then be exported to a .csv file and can be ingested into other tools for analytics.

Azure Storage Account and Table

Open the Azure portal and create a new Storage Account. Keep all of the defaults and step through the wizard.

Once the deployment is complete, navigate to the Storage Account and select Tables. In this view, create a table named “domaineddevices”:

After creating the Table, navigate to the Access keys blade. Copy this key and paste it into the $accesskey line in the script below:

For better compatibility in your environment, change the Minimum TLS version to 1.0 under the Configuration blade. This will allow older versions of Windows to check in with the Table:

Once this Storage Account is setup, move to the Powershell section and paste in your Key that you copied earlier.

Powershell script

I was struggling with writing to an Azure Table, specifically creating the needed encryption pieces. I found a few posts [A] [A] that had the main crypto pieces that I needed. I wrote the rest of the information gathering lines and tweaked it to successfully upload the data that the script gathered to Azure Tables.

Here's my modified Powershell script:

# Check-DomainStatus.ps1

$ScriptVersion = 20220802

Start-Transcript -Path 'C:\temp\Check-DomainStatus.log' -Append -NoClobber
$storageAccount = 'STORAGEACCOUNT' # Update these values for your environment
$accesskey = 'XXX' # Update these values for your environment
$TableName = 'domaineddevices'
$DomainName = 'XXX' # Update these values for your environment

function InsertReplaceTableEntity($TableName, $PartitionKey, $RowKey, $entity) {
    $version = "2017-04-17"
    $resource = "$tableName(PartitionKey='$PartitionKey',RowKey='$Rowkey')"
    $table_url = "https://$storageAccount.table.core.windows.net/$resource"
    $GMTTime = (Get-Date).ToUniversalTime().toString('R')
    $stringToSign = "$GMTTime`n/$storageAccount/$resource"
    $hmacsha = New-Object System.Security.Cryptography.HMACSHA256
    $hmacsha.key = [Convert]::FromBase64String($accesskey)
    $signature = $hmacsha.ComputeHash([Text.Encoding]::UTF8.GetBytes($stringToSign))
    $signature = [Convert]::ToBase64String($signature)
    $headers = @{
        'x-ms-date'    = $GMTTime
        Authorization  = "SharedKeyLite " + $storageAccount + ":" + $signature
        "x-ms-version" = $version
        Accept         = "application/json;odata=fullmetadata"
    }
    $body = $entity | ConvertTo-Json
    Invoke-RestMethod -Method PUT -Uri $table_url -Headers $headers -Body $body -ContentType application/json
}

# GPO calculation
$RegPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}'
$LowTime = Get-ItemProperty -path $RegPath -name "EndTimeLo"
$HighTime = Get-ItemProperty -path $RegPath -name "EndTimeHi"
$CompTime = ([long]$HighTime.EndTimeHi -shl 32) + [long] $LowTime.EndTimeLo
$GPOProcessDate = [DateTime]::FromFileTime($CompTime)

# Reduce some calls
$dsregcmd = (C:\Windows\System32\dsregcmd.exe /status)
$computerinfo = Get-ComputerInfo 
$wmiobjectw32 = Get-WmiObject -class win32_bios

$body = @{
    # Required values 
    RowKey                     = $($env:COMPUTERNAME)
    PartitionKey               = 'domaineddevices'

    # Optional values
    AzureADJoinedStatus        = ($dsregcmd | Select-String 'AzureADJoined' | Out-String).replace(' ', '').replace("`n", '').replace("`r", '')
    AdminAccountPresent     = if ((Get-LocalUser).Name -Contains 'LocalAdmin' ) { $true } else { $false }
    Domain                     = $env:USERDOMAIN
    DomainJoinStatus           = ($dsregcmd | Select-String 'DomainJoined' | Out-String).replace(' ', '').replace("`n", '').replace("`r", '')
    EnterpriseJoinedStatus     = ($dsregcmd | Select-String 'EnterpriseJoined' | Out-String).replace(' ', '').replace("`n", '').replace("`r", '')
    FortiClientVPNFilesPresent = if (Test-Path -Path 'C:\Program Files\Fortinet\FortiClient' -ErrorAction SilentlyContinue) { $true } else { $false }
    FortiClientVPNRunning      = if (Get-Process -ProcessName 'FortiTray' -ErrorAction SilentlyContinue) { $true } else { $false }
    # # GPOProcessDate             = [datetime]::FromFileTime(([Int64] ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeHi) -shl 32) -bor ((Get-ItemProperty -Path "Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Extension-List\{00000000-0000-0000-0000-000000000000}").startTimeLo)).toString()
    GPOProcessDate             = [datetime]$GPOProcessDate
    LogonServer                = $env:LOGONSERVER | Out-String
    Manufacturer               = ($wmiobjectw32).Manufacturer
    NetworkMAC                 = (Get-WmiObject win32_networkadapterconfiguration | Select-Object Description, MACaddress, IPAddress, DefaultIPGateway, DNSDomain) | Out-String
    OSBuild                    = (($computerinfo).OsHardwareAbstractionLayer | Out-String).replace(' ', '').replace("`n", '').replace("`r", '')
    OSEdition                  = (($computerinfo).WindowsProductName | Out-String).replace(' ', '').replace("`n", '').replace("`r", '')
    OSVersion                  = [int32]((($computerinfo).WindowsVersion | Out-String).replace(' ', '').replace("`n", '').replace("`r", ''))
    QuestODMAgentRunning       = if (Get-Process -ProcessName 'BinaryTree.ADM.Agent' -ErrorAction SilentlyContinue) { $true } else { $false }
    QuestODMFilesPresent       = if (Test-Path -Path 'C:\Program Files (x86)\Quest\On Demand Migration Active Directory Agent' -ErrorAction SilentlyContinue) { $true } else { $false }
    ScriptVersion              = [int32]$ScriptVersion
    SerialNumber               = ($wmiobjectw32).SerialNumber
    StorageType                = (Get-PhysicalDisk).MediaType | Out-String
    Traceroute                 = (Test-NetConnection -TraceRoute $DomainName -Hops 5 -ErrorAction SilentlyContinue) | Out-String
    Uptime                     = (New-TimeSpan -Start (Get-CimInstance -Class Win32_OperatingSystem -Property LastBootUpTime).LastBootUpTime -End (Get-Date)).ToString()
    Users                      = (Get-ChildItem -Path 'C:\Users\' | ForEach-Object {
            $size = Get-ChildItem -Path $_.FullName -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Average -Sum -ErrorAction SilentlyContinue
            Write-Output $_.Name, $_.LastWriteTime.ToString("yyyy-MM-dd"), "$([math]::round($size.sum/1GB)) GB", '---' }) | Out-String
    WindowsVPNManualStatus     = (Get-VpnConnection -ErrorAction SilentlyContinue).Name | Out-String
    WindowsVPNStatus           = (Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue).Name | Out-String
}

Write-Host 'Creating new or updating table entity'
InsertReplaceTableEntity -TableName $TableName -entity $body -RowKey $body.RowKey -PartitionKey $body.PartitionKey

Write-Host 'Outputting all values for log:'
Write-Host $body 
Stop-Transcript

Save that script to somewhere like SYSVOL.

Group Policy Object

After saving the file to the domain controller, create a GPO with the following items:

Computer Configuration > Preferences > Windows Settings > File

General tab:

• Source file(s): \\domain.local\SYSVOL\domain.local\scripts\Check-DomainStatus.ps1

• Destination FIle: C:\temp\Check-DomainStatus.ps1

Computer Configuration > Control Panel Settings > Scheduled Tasks

General tab:

• Action: Replace

• Name: Check-DomainStatus

• When running the task, use the following user account: NT AUTHORITY\System

• Run whether user is logged on or not

• Run with highest privileges

• Configure for: Windows Vista or Windows Server 2008

Triggers tab:

• New > Begin the task: On a schedule

• Daily, Recur every: 1 days

• Repeat task every: 1 hour for a duration of: 1 day

• Enabled

Actions tab:

• New > Action > “Start a program”

• Program/script: powershell.exe

• Add arguments(optional): -NoProfile -ExecutionPolicy Bypass -File "c:\temp\Check-DomainStatus.ps1"

Conditions tab:

• All options unchecked.

Settings tab:

• Allow task to be run on demand

• Run task as soon as possible after a scheduled start is missed

• Stop the task if it runs longer than 1 hour

• If the running task does not end when requested, force it to stop

• If the task is already running, then the following rule applies: Do not start a new instance

Once deployed, the task will be available on the local machine in Task Scheduler and can be started immediately:

Azure Storage Explorer

After deploying the script, you can use the Azure Storage Explorer app to view and export the data as it arrives:

Discuss...

#Azure

I received a request for a hosted SFTP solution for one of the clients I work with.

Currently, there are some recommended templates from Microsoft [A] that include Blob storage and a Debian container that serves up the SFTP service. While this solution will work, I'm looking for a solution that's easier to manage.

Recently in Preview, Azure now has the ability to add the SFTP endpoint and features to a Storage Account.

Here's how you do it.

Open the Azure Portal and create a new Storage Account. You should be able to add this feature to existing Storage Accounts, as long as they are StorageV2 (general purpose v2) of Block Blob.

On the Advanced tab, check the boxes for “Enable hierarchical namespace” and “Enable SFTP (preview)”:

Leave the rest of the options as defaults.

After creating the resource, navigate to the “SFTP (Preview)” blade under the Settings header. From there, click “Add local user”. Type the name for the user and check the box to use an SSH Password:

Still in the “Add local user” side menu, click on the “Container permissions” tab and add a new container that you plan to use for storage. Change the permissions to fit what kind of access you need, then set the “Home directory” to the virtual folder you want to use. If this value is not set correctly, you'll have connection/mounting issues later on. To keep things simple, I set it to the Container that I set in the top row:

Copy the SFTP user password somewhere like Notepad and return to the SFTP blade.

After getting the SFTP features set up, you can connect to your container using the connection information in the “Connection string” option. Click on the Copy icon:

Next, get an SFTP app like Filezilla to setup the connection. Paste the “Connection string” into Filezilla's “Host” field. The username will populate from this information. Paste in the password that you saved from earlier, then click “Quickconnect”:

And that's it!

For it to be fully featured, there are a few things that I would like to see added (the ability to use Azure AD accounts and Managed Identities). Right now, it's working great as a fully managed SFTP endpoint that you can use for a few dollars per month: It supports regular Blob features (Soft Delete, Azure Monitoring and Firewalls, etc.) and can hook into a vNet using a Service Endpoint.

---

Additional resources:

• https://docs.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support
• https://docs.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-known-issues

Discuss...

#Azure #Powershell

If you have a ton of compute and storage resources in your Azure environment, it can be difficult to tell which managed disks are orphaned or not mounted to a virtual machine. This Microsoft Doc [A] has the AZ CLI command, but it's buried in a larger task to delete the found objects. This Docs page also doesn't have the Powershell equivalent and I prefer to use Powershell.

To find these disks, run one of these commands in a Cloud Shell or other Azure connected terminal:

AZ CLI:

az disk list --query '[?managedBy==`null`].[id]' -o tsv

Powershell:

Get-AzDisk | Where-Object {$_.ManagedBy -eq $null}

Discuss...

#Windows #Azure #AzureAD

If you've deployed an Azure VM and did not enable the “Login with AAD credentials”, option, you can enable sign in using Azure Active Directory credentials later using Cloud Shell with this command in Azure CLI:

az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory \
--name AADLoginForWindows \
--resource-group ResourceGroup \
--vm-name VMName

After running that command, you'll need to add an entry to the local group to allow interactive sign in using RDP. The extension doesn't add this permission and you will need to do it manually, running this command in a remote Powershell:

net localgroup "remote desktop users" /add "AzureAD\user@domain.com"

You will also need to add 2 lines the RDP file downloaded from the “Connect” tab so that you can connect without issues:

enablecredsspsupport:i:0
authentication level:i:2

After connecting to the VM using RDP, you will also need to disable network-level authentication from Control Panel.

In the background, the extension will change the Join Type of the VM to “Azure AD Joined” and your Devices blade will update with that information after a couple of minutes.

No need to re-create the VM.

Just putting this here for my notes.

Discuss...