Unlicensed OneDrive charges as of Jan 2025 and analysis

If you work in a MS-based environment, it is likely you have seen that as of January 27th 2025, you will start getting charged for retained OneDrive data.

https://learn.microsoft.com/en-us/sharepoint/unlicensed-onedrive-accounts?WT.mc_id=365AdminCSH_spo 

The storage cost for the will be $US 0.05/GB/Month – which can add up very quickly.

https://mc.merill.net/message/MC836942

In the environment i’ve recently started working in, there was a guy who was previously working in the role, who i am growing to absolutely despise, who made sure that we would experience maximum hassle when trying to extricate ourselves from his exceedingly poor and short-sighted decisions.

 

Step 1 – Determine the size of the issue

  • Go to SharePoint admin center > Reports > OneDrive accounts
  • You will be presented with the size of your issue immediately. Here is an example from my work tenant.
  • Assuming you have an issue, click “Download report”
  • This report will give us three important things
    • The direct urls for the onedrive sites we are interested in looking at
    • The reason the OneDrive is unlicensed
    • Why the deletion has been blocked

Step 2 – Analysing the report data

  • In the “Unlicensed due to” column you will see 3 options
    • Owner deleted from EntraID
      • Reasonably self-explanatory. The account has been deleted, but importantly, no-one else has been granted ownership over the OneDrive – and it is likely safe to delete
    • License removed by admin
      • License has been removed, but the user still exists. In our environment this seemed to be mainly shared resources that were accidentally allocated a license when they were created.
    • Duplicate account
      • This generally indicates that ownership of the OneDrive has been reallocated to another current user. It can also occur when a user leaves and comes back and the “old” OneDrive is still there due to a retention policy.
  • In the “Delete blocked by” column you also will see 3 options
    • Retention period
      • This is the OneDrive retention period for unlicensed users as specified here
      • https://<YourSiteName-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/settings/OrphanedPersonalSitesRetentionPeriod
      • As you can see – ours is set 2555 days…. or 7 years.
    • Retention policy
    • Owner active in Entra ID
      • This means that another user, who is active has been granted access over the OneDrive.
  • For us at least, all entries are blocked by both the OneDrive retention period and the retention policy. Some are (in addition to the other two) also blocked by “Owner active in Entra ID”

Step 3 – an approach to sorting through this mess

  • Take the .csv downloaded in step 1 and open it in Excel
  • Enable auto-filter – and class the deleted OneDrives into 3 categories
    • “Owner deleted from EntraID”
      • In my instance, there was general agreement that where the user has simply been deleted, that we didn’t need to do any further analysis on these accounts. An email would be sent out to business to explain that old OneDrive accounts would no longer be available as of x. The problem is here of course, that many users don’t know if/when they are accessing a file from a shared OneDrive.
    • “License removed by admin”
      • We need to find out more details here, such as if the account is a shared mailbox that was accidentally licensed. Who the owner is. Does the OneDrive contain any data etc.
    • “Duplicate account”
      • These are the OneDrives that are most likely to be in active use and require further analysis

 

Step 4 – Slightly more detailed analysis

  • As per anything that is in anyway related to sharepoint, this is way harder than it needs to be.
  • Filter the Excel document to your desired list (.e.g duplicate accounts)
    • Copy and paste the urls into a txt document and use it to drive the following script
    • Note : This script will grant your admin account “SiteCollection” admin rights! If you need to seek permission to do this from management first – do that before running this script!

# Connect to SharePoint Online Admin Center
$adminSiteUrl = “https://<YourSite>-admin.sharepoint.com”
Connect-SPOService -Url $adminSiteUrl

# Path to the text file with the list of OneDrive URLs
$onedriveUrlsFilePath = “C:\Temp\DuplicateAccount.txt”

# Path to the output CSV file
$outputCsvFilePath = C:\Temp\DuplicateAccount.csv”

# Import the OneDrive URLs from the text file
$onedriveUrls = Get-Content -Path $onedriveUrlsFilePath

# Initialize an empty array to store the results
$onedriveDetails = @()

# Loop through each OneDrive URL
foreach ($onedriveUrl in $onedriveUrls) {
# Get site details (StorageUsageCurrent and LastContentModifiedDate)
Write-host “Getting details for account: $onedriveUrl”
$siteDetails = Get-SPOSite -Identity $onedriveUrl -Detailed

#Grant siteAdmin permissions
Set-SPOUser -Site $oneDriveUrl -LoginName <YourAdminUsername> -IsSiteCollectionAdmin $true

$SiteAdmins = Get-SPOUser -Site $onedriveUrl -Limit All | Where-Object { $_.IsSiteAdmin -eq $true }
$SiteMembers = Get-SPOUser -Site $onedriveUrl -Limit All | Where-Object { $_.IsSiteAdmin -eq $false }

# Store the details in a PowerShell object
$onedriveInfo = [PSCustomObject]@{
URL = $onedriveUrl
Owner = $siteDetails.Owner
StorageUsageCurrent = $siteDetails.StorageUsageCurrent
LastContentModifiedDate = $siteDetails.LastContentModifiedDate
SiteAdmins = ($SiteAdmins | ForEach-Object { $_.LoginName }) -join “; ”
SiteMembers = ($SiteMembers | ForEach-Object { $_.LoginName }) -join “; ”
}

# Add the details to the array
$onedriveDetails += $onedriveInfo
}

# Export the details to a CSV file
$onedriveDetails | Export-Csv -Path $outputCsvFilePath -NoTypeInformation

 

The output from this script will give you a csv with

  • The URL
  • Owner
  • Current usage
  • Last content modified date
  • Login ID’s of accounts that have SiteAdmin permissions
  • Login ID’s of accounts that are site members – meaning that at some stage, the original user has shared a folder or document with one of these users from their OneDrive.

From here – you now are starting to get enough information to track down possible usages of these “old” OneDrives.

Now – if your anything like us – there is waaaay to many permissions in order for anyone to track all these down by contacting the users in question.

Step 5 – Potential “solutions”

  • Now… solutions may be a bit of a strong word here…. so perhaps lets go with “ways of gradually vetting then removing access to data prior to it being deleted to improve your chances of not deleting something important”
  • If someone wants to view a OneDrive contents before being deleted, you can grant them site collection admin via
    • GUI : <TheURLtoTheUsersOneDrive>/_layouts/15/mngsiteadmin.aspx (copy the url from the spreadsheet you created in step1)
    • Powershell : Set-SPOUser -Site <TheURLtoTheUsersOneDrive> -IsSiteCollectionAdmin:$true -LoginName <UPNofUserToGrantAccessToo>
  • Due to a large number of members potentially having access to files in someone’s onedrive – and not knowing that they are accessing it from someone’s OneDrive, we can
    • Record who has access using the script above
    • Perform a scream test for a period of time by removing member access by using the following script

# Connect to SharePoint Online Admin Center
$adminSiteUrl = “https://<YourSite>-admin.sharepoint.com”
Connect-SPOService -Url $adminSiteUrl

# Path to the text file with the list of OneDrive URLs
$onedriveUrlsFilePath = “C:\Temp\Testing2.txt”

# Define the log file path
$logFilePath = “C:\Temp\Testing2.log”

# Import the OneDrive URLs from the text file
$onedriveUrls = Get-Content -Path $onedriveUrlsFilePath

# Function to log the removal of a user
function Log-UserRemoval {
param (
[string]$siteUrl,
[string]$userName
)
$timestamp = Get-Date -Format “yyyy-MM-dd HH:mm:ss”
$logEntry = “$timestamp – Removed user: $userName from site: $siteUrl”

# Append the log entry to the log file
Add-Content -Path $logFilePath -Value $logEntry
Write-Host $logEntry
}

# Loop through each OneDrive URL
foreach ($onedriveUrl in $onedriveUrls) {
Write-host “Getting details for account: $onedriveUrl”
# Define the OneDrive or SharePoint site URL
$siteUrl = $onedriveUrl

# Get all users from the site
$users = Get-SPOUser -Site $siteUrl -Limit All

# Loop through each user and check if they are not a site admin and if their username ends with @<yourDomainSuffix>
foreach ($user in $users) {
if ($user.IsSiteAdmin -eq $false -and $user.LoginName -like “*@<yourDomainSuffix>”) {
# Remove the user from the site if their login ends with <yourDomainSuffix>
Write-Host “Removing user: $($user.LoginName)”
Remove-SPOUser -Site $siteUrl -LoginName $user.LoginName

# Log the removal of the user
Log-UserRemoval -siteUrl $siteUrl -userName $user.LoginName
}
}

}

 

That’s my current best shot at this…. will be interested to hear if any of you have additional/different ways of tackling this mess, while the rest of organisation is like the below:

Other

Other random commands i found helpful

Build a list of all OneDrive urls

from https://learn.microsoft.com/en-us/sharepoint/list-onedrive-urls

$TenantUrl = Read-Host “Enter the SharePoint admin center URL”
$LogFile = [Environment]::GetFolderPath(“Desktop”) + “\OneDriveSites.log”
Connect-SPOService -Url $TenantUrl
Get-SPOSite -IncludePersonalSite $true -Limit all -Filter “Url -like ‘-my.sharepoint.com/personal/'” | Select -ExpandProperty Url | Out-File $LogFile -Force
Write-Host “Done! File saved as $($LogFile).”

In particular, update the “Url -like ‘-my.sharepoint.com/personal/'” to include part of a username you are interested in e.g. “Url -like ‘-my.sharepoint.com/personal/mike'”

WSUS is now deprecated

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/windows-server-update-services-wsus-deprecation/ba-p/4250436

Not really surprising – there hasn’t been any meaningful updates to WSUS for a very long time… there are improvements that could be made – but no appetite to make them…. i imagine because the cloud solutions have a direct cost (and are therefore revenue producing) whereas WSUS does not.

The argument could be made that the ability to patch en-mass via products such as WSUS (and by extension, SCCM) is part of what you are paying for when you pay for a Windows license… the same as the the idea that you’re paying for supported product… its all part of the eco-system…. and without support, or patching or sysinternals tools or <insert other tools here> the Windows eco-system becomes much less attractive.

Anyhoo – obviously not the way the MS management see things…. it appears as if anything that doesn’t have a direct revenue stream associated with it is being killed off. Not surprising – but it also really sucks being shoe-horned into a immature platform that doesn’t always fit business or technical needs.

Removing EXO litigation holds and making your mailbox functional again

Recently i had a situation where a user with a shared mailbox which had a ludicrous number of items. He recently started in the role and wanted to “start fresh” – but items could not be deleted.

A quick investigation found that litigation hold had been enabled for the mailbox (in addition to our org wide retention policies). It was unclear why the litigation hold had been enabled – and the reasons were lost due to staff turnover.

Finding and fixing the issue included:

  • get-mailbox <identity> | fl *hold*
    • This command will show the status of all holds on that specific mailbox. In my case, i could see that “LitigationHoldDate” and “DelayHoldApplied” were populated
    • In order to remove these i ran
      • get-mailbox <identity> | Set-Mailbox -LitigationHoldEnabled $false
      • get-mailbox <identity> | Set-Mailbox -RemoveDelayHoldApplied
  • After running these steps – i was still not able to delete items from the mailbox, so i ran
    • get-mailboxFolderStatistics <identity> -FolderScope RecoverableItems | FL Name,FolderAndSubfolderSize,ItemsInFolderAndSubfolders
    • and could see that the recoverable items and purges were both at 100GB – meaning that the quota, which also applied to delete items was full – so i could not yet delete anything more
    • In order to speed up the process of the managed folder assistant doing its job, run
      • Start-ManagedFolderAssistant -Identity <identity> -FullCrawl -HoldCleanup
    • After some time, if you re-run the get-mailboxFolderStatistics command, you should see the recoverable items and purges start to come down
  • Since this mailbox was full and is receiving a very high volume of new mail – the 100GB limit was going to be hit again very quickly – so in order to mitigate that for this initial cleanup, i then set
    • Set-Mailbox -Identity <identity> -RetainDeletedItemsFor 1
    • This will only detain deleted items for 1 day in the dumpster before purging
    • I will set this back to 30 days once the initial cleanup is complete and the mailbox is back to “normal” operation.
  • If the mailbox also has a retention policy in addition to the litigation hold
    • get-mailbox -Identity <identity> -Archive | fl *holds*
      • Take note of the ID of the in place hole
    • Connect-IPPSSession
    • Get-RetentionCompliancePolicy | fl Name,ExchangeObjectId
      • Match up the id of the retention policy to a name
    • Set-RetentionCompliancePolicy -Identity <NameOfPolicy> -AddExchangeLocationException <useridentity>
    • Get-Mailbox <identity> | FL DelayHoldApplied,DelayReleaseHoldApplied
    • Set-Mailbox <identity> -RemoveDelayHoldApplied
    • Set-Mailbox <identity> -RemoveDelayReleaseHoldApplied
    • Start-ManagedFolderAssistant -Identity <identity> -FullCrawl -HoldCleanup
    • <wait>
    • To check the status, use
      • get-mailboxFolderStatistics <identity> -FolderScope RecoverableItems | FL Name,FolderAndSubfolderSize,ItemsInFolderAndSubfolders

I’ve read some articles that say that “Start-ManagedFolderAssistant” needs to be run twice to pick up the new settings – but its all a bit of black magic because we cant see what is happening at the backend…. i tend to run it two or three times – as if those articles are right, im speeding things up, if they are wrong, there is no visible harm.

Crowdstrike BSOD and GPO no longer updating

After the Crowdstrike BSOD’s on 19/07/2024 – we have seen a significant uptick on clients not refreshing group policy.

The machines in question can be identified via:

  • The last update file date on C:\Windows\System32\GroupPolicy\Machine\registry.pol being on or around 19/07/2024 (some were on the 20th or 21st for us)
  • Event ID 1096 in the system event log with a line similar to “The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure”

The fix itself is very simple, delete the file C:\Windows\System32\GroupPolicy\Machine\registry.pol… but in an environment which does not have SCCM on all endpoints (which is incredibly frustrating), the following can be utilised to identify the machines suffering from the issue. The following script also checks for setup log event ID 1015 – indiciating Windows component store corruption… far less common – but we’ve also had some of that (although im less including to think this is Crowdstrike related and more just the poor maintenance of machines)

Obviously you could also add the code to delete the file when found – but at this point, i just needed to identify.


# Define the path to the input file containing the list of machines
$inputFilePath = “<path to txt file with computer list – could also run against AD if you wanted>”

# Define the output file to store the results
$outputFilePath = “<outputpath>\results.csv”

# Import the list of machines from the text file
$machines = Get-Content -Path $inputFilePath

# Initialize an array to hold the results
$results = @()

foreach ($machine in $machines) {
# Trim any leading/trailing whitespace
$machine = $machine.Trim()

# Ping the machine to check if it’s online
if (Test-Connection -ComputerName $machine -Count 1 -Quiet) {
Write-Host “$machine is online.”

# Define the path of the file to check
$filePath = “\\$machine\C$\Windows\System32\grouppolicy\machine\registry.pol”

# Check if the file exists and get the last write time
if (Test-Path -Path $filePath) {
$fileDate = (Get-Item -Path $filePath).LastWriteTime
Write-Host “File found on $machine. Last modified on: $fileDate.”
} else {
Write-Host “File not found on $machine.”
$fileDate = $null
}

# Check for Event ID 1096 in the System log within the last 7 days
$event1096 = Get-WinEvent -ComputerName $machine -FilterHashtable @{LogName=’System’; Id=1096; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue

# Check for Event ID 1015 in the Setup log within the last 7 days
$event1015 = Get-WinEvent -ComputerName $machine -FilterHashtable @{LogName=’Setup’;Id=1015; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue

# Determine the status of the events
$event1096Status = if ($event1096) { “Event 1096 Found” } else { “Event 1096 Not Found” }
$event1015Status = if ($event1015) { “Event 1015 Found” } else { “Event 1015 Not Found” }

# Add the result to the array
$results += [PSCustomObject]@{
Machine = $machine
Online = $true
FileDate = $fileDate
Event1096 = $event1096Status
Event1015 = $event1015Status
}
} else {
Write-Host “$machine is offline.”

# Add the result to the array
$results += [PSCustomObject]@{
Machine = $machine
Online = $false
FileDate = $null
Status = “Offline”
Event1096 = “N/A”
Event1015 = “N/A”
}
}
}

# Export the results to a CSV file
$results | Export-Csv -Path $outputFilePath -NoTypeInformation

Write-Host “Results have been saved to $outputFilePath.”

 

RDS Session hosts don’t accept new connections after reboot – despite not being in drain mode

Recently – i have had the following scenario:

RDS Farm with 2 x DNS-RR brokers and approx 30 session hosts, all server 2022.

Some session hosts, seemingly randomly, after a reboot will all look ok, but won’t accept any connections.

cycling the session host to not accept new connections/accept new connections would bring the server “back”

After looking through the logs and posting on a few forums (and getting some exceedingly poor responses) – i came to a point where i knew i could implement a “hack” – but would prefer to find the root cause.

To that end, i engaged Andy from https://purerds.org/ – who i’d previously worked with and seems to have that “next level” RDS knowledge – partially for a sanity check that i hadn’t missed something – and partially with the hope that he had seen this before.

The guts of it is:

  • In SQL – the RDSHProperty table shows a “drainmode” of “0” for all servers – so the servers not accepting connections is not recognised by the brokers (as we expected)
  • In SQL – the TargetProperty table shows a “serverMaxActiveSessions” of “10000” for all servers – in line with the above
  • In the log “Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”
    • We can see the server leave the farm @ 1am (reboot time) with
      • Event Id 1283
      • Remote Desktop Services successfully left a farm on the Connection Broker server <broker1>;<broker2>
    • But no corresponding entry to re-join the farm (unlike the healthy servers)
  • If I restart the service “TermService” on the local server, I get the following events (as expected – but just for the sake of documenting things)
    • EventId 1280 – Remote Desktop Services failed to join the Connection Broker on server <broker1>;<broker2>. Error: Current async message was dropped by async dispatcher, because there is a new message which will override the current one.
    • EventId 1281- Remote Desktop Services successfully joined a farm on the Connection Broker server <broker1>;<broker2>

In the end, we were unable to find a root cause, so i ended up using the following powershell script as a scheduled task on each session host:

$LogPath = “C:\Windows\Temp”
$LogName = “RDSRestartOnJoinFail.log”
$startTime = (Get-Date).AddHours(-12)

#Logging
Function Write-Log {
[CmdletBinding()] param(
[Parameter()] [ValidateNotNullOrEmpty()] [string]$Message,

[Parameter()] [ValidateNotNullOrEmpty()] [ValidateSet(‘Information’,’Warning’,’Error’,’Success’,’Break’)] [string]$Severity = ‘Information’,

[Parameter()] [ValidateNotNullOrEmpty()] [ValidateSet(‘Console’,’LogFile’,’Both’)] [string]$LogType = ‘Console’
)

$Date = (Get-Date).toString(“yyyy/MM/dd HH:mm:ss”)
$LogString = $Date + “, ” + $Severity + “, ” +$Message
If ($LogType -eq “Console” -or $LogType -eq “Both”) {
If ($Severity -eq “Information”) { Write-Host $LogString -foregroundColor Blue}
If ($Severity -eq “Warning”) { Write-Host $LogString -foregroundColor Yellow}
If ($Severity -eq “Error”) { Write-Host $LogString -foregroundColor Red}
If ($Severity -eq “Success”) { Write-Host $LogString -foregroundColor Green}
If ($Severity -eq “Break”) { Write-Host $LogString -foregroundColor White}
}

If ($LogType -eq “LogFile” -or $LogType -eq “Both”) {
Add-Content $LogPath\$LogName -value $LogString }
}

#Main
$Events = Get-WinEvent -FilterHashtable @{ProviderName = “Microsoft-Windows-TerminalServices-SessionBroker-Client”; LogName = “Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”; id=’1281′; StartTime = $startTime} -ErrorAction SilentlyContinue

if ($events.Count -eq 0) {
Write-Log -Message “No events with ID 1281 found in the past 12 hours – Can assume that machine has not re-joined the farm. Restarting TERMSERV service” -Severity Warning -LogType LogFile
Restart-Service -Name TermService -Force
} else {
Write-Log -Message “$($events.Count) events with ID 1281 found in the past 12 hours – Can assume that machine HAS re-joined the farm” -Severity Information -LogType LogFile
}

Pet insurance australia – just shit…

Dogs…. just fluffy balls of awesomeness right ?

Just like we have health insurance, i got pet insurance for our first Golden Retriever – who turned 11 a last month, through Pet Insurance Australia… as they seemed to be ok-ish based on the online reviews… acknowledging that its incredibly difficult to discern a real review from a bot-farm review anymore.

He’s had a full life of playing with other dogs (his favourite), his little human, his therapy dog work and the rest of our family… like most goldens, he’s pretty much universally loved… because he’s fucking awesome and might well be the nicest creature on the planet – ever.

All the way back in 2016, i got pet insurance for him because – risk and risk mitigation. At the time it was around the $500 a year mark.

Fast forward to yesterday (July 2024) – the premiums are now approx $2200 for the upcoming renewal. One one hand, i understand inflation and that his risk profile has changed now he’s older… on the other – isn’t that what i paid premiums for the last 8 years to help cover ?

When i rang to cancel the policy, i got the same old bullshit, including an offer to give us 3 months free… which really sealed the deal for me. If you can offer 3 months for free, then you’re just price gouging (like most corporates at the moment, i’m not saying this is isolated) rather than increasing prices in line with inflation.

Fuck you Pet Insurance Australia…. there aren’t many sacred things left in the world – but the health of doggies everywhere is one of them – you don’t fuck with that…. may you all get bowel cancer and die a long, incredibly painful death.

Moving from Synology to QNAP

My Synology 2413+ 12 bay NAS recently died after 12 years of service.

This NAS was primarily used as:

  • an iSCSI backup target for Veeam
  • Video recording for home security cameras
  • Media storage

Overall, i was pretty happy with the unit itself – but as per most companies these days, support was non-existent…. so when i did run into an issue, i was on my own.

Due to that, and Synology not being able to answer what would happen with my surveillance station licenses, i made the decision to go for a QNAP as:

  • It was a little cheaper for better hardware specs (this is in the 8-bay desktop model i was looking at – may be different for other models)
  • QVRPro – the equivalent of Synology surveillance station is free for up to 8 cameras – and i only use 4. There is apparently a 14 day retention time on video at the “free” license level…. and while i would prefer it to be 31 days…. its going to be fine most of the time.

In the ways im interested in, the QNAP has so far proven to be quite good, its setup and joining to an AD domain was simple and painless, adding disks, storage pools and volumes was easy and clear, QVRPro setup had very minor hiccups (more due to my understanding than the software)… but, it hasn’t been all great. The issues i have noticed so far:

  • The lack of a Synology Hybrid RAID equivalent isn’t a disaster, but disappointing…
  • Due to the above, i have purchased some more 8TB disks (previously had a mix of 6TB and 8TB) – the time taken to expand/repair is significant (as expected) – but the poor thing has been the performance of the device while this is occuring. Trying to stream anything during this process has been pointless – with constant dropouts. Having the performance degrade during a repair or expand is not unexpected – but not to the point of drop-outs.

Will be interested to see the performance difference once the rebuild has finished.

Win RM fails on DC with event ID 142

For a while i have had a niggling issue where on a DC that is used by a number of in-house coded applications, WinRM would fail intermittently with the following:

Log : Microsoft-Windows-WinRM/Operational

EventID : 142

Event Message: WSMan operation Enumeration failed, error code 2150859046

There isn’t much to go on for this error when googling – and MS support – well… no point in trying that.

After verifying permissions and configuration, checking server resources etc… i was at a point where i didnt know how to “fix” it or even have any leads.

I initially put in a simply script to restart the service nightly… but every now and again, the stop of the service would hang…. so i’d have to kill the process.

I’ve ended up going down a path of:

  • Attaching a scheduled task to eventID 142
  • To get around powershell restrictions – have it launch a batch file containing

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /t REG_SZ /d unrestricted /f
powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Unrestricted -File C:\data\TerminateAndRestartWinRM.ps1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /t REG_SZ /d AllSigned /f

TerminateAndRestartWinRM.ps1 contains

Start-Transcript C:\Data\WinRMTerminate.log

write-host “Getting the WinRM ProcessID”
$winRMService = Get-WmiObject -Class Win32_Service -Filter “Name=’WinRM'”
$processId = $winRMService.ProcessId

write-host “Terminating processID: $ProcessId”
Stop-Process -Id $processId -Force

write-host “Sleeping for 10 seconds to wait for process to terminate”
Start-Sleep -seconds 10

write-host “Starting WinRM”
# Start the WinRM service
Start-Service -Name WinRM

Stop-Transcript

 

Not the best thing ever – and i generally don’t like these types of “hacky” solutions…. but given that MS has moved from “mostly unsupported” to “completely unsupported” for everything that isn’t in Azure…. (which even then is mostly unsupported)… we don’t have much choice anymore.

AlwaysON VPN breaks after root certificate update

Scenario

  • After updating the internal CA root certificate, AlwaysOn VPN stops working with an error (at the user end) of “A Certificate could not be found that can be used with this Extensible Authentication Protocol
  • In this case, we were using an Enterprise integrated CA and renewed the root using the same signing keys – which should ease the process – at least for all windows clients
  • AOVPN is configured to use PEAP for authentication

 

Troubleshooting

  • Initially, 4 out of the 6 AOVPN servers had not received the new root cert from a GPupdate yet – so i forced that, restarted the service, but no difference
  • We discovered that the issue only occured on devices which had the updated trusted root cert in trusted root store. Additionally, for those that had updated, if we deleted the updated trusted root cert, AOVPN would connect again
  • We quickly found this article by the doyen of DirectAccess and AOVPN – https://directaccess.richardhicks.com/2020/10/19/always-on-vpn-ipsec-root-certificate-configuration-issue/  
    • While its a good article – it ended up not being our issue and actually led our down the wrong path a little
    • At the same time, for someone that wasn’t overly familiar with AOVPN (This was implemented by someone else and i’ve not had much to do with AOVPN) it was great, because i could look at the scripts and suss out some of the relevant powershell commandlets
  • After checking and re-checking every setting under the sun, a colleague could connect again after updating the client end
  • Once she worked that out, we then clarified and replicated the change on a different machine to be sure – and confirmed it was all good

 

Resolution

  • On a client machine, we updated the AOVPN configuration to include (i.e. tick the new as well as the old root cert) the updated root cert in 3 places under
    • <AOVPN connection name> / Properties / Security / Properties
    • <AOVPN connection name> / Properties / Security / Properties /Configure
    • <AOVPN connection name> / Properties / Security / Properties /Configure / Advanced
  • Confirm that the AOVPN connection is working
  • Export the profile using the script from https://directaccess.richardhicks.com/tag/profilexml/
  • Look at the xml – you should now see the thumbprints of both the “old” and “new” root certificate listed in multiple sections
  • Copy the section <EAPHostConfig> from its open xml tag to its close xml tag and insert into the “EAP xml” part of intune AOVPN configuration

Documenting AD ACL’s

A while ago i joined an organisation whose MS estate was in need of a significant amount of love, time and effort. Getting them off of 2012 R2 DC’s and onto 2022 DC’s, upgrading the forest/domain functional levels and getting replication times down were the obvious first jobs… but once they were done – there was so many other things to do – it was hard to know what to go with first. So… i made a start on all of it at once – knowing that it would probably take all year to get the AD into a semblance of decent condition.

The more i looked, the more i found… one thing that was/is particularly disturbing is that the DS ACL’s have been fucked with at the top level – and flowed down to all descendant objects for some admin accounts, service accounts etc…. stuff that clearly doesnt need, or has never needed that level of access….

Before changing anything, the goal is to document the permissions – as is a spaghetti of inherited, non-inherited and multi-nested groups applied at many different levels…. resulting in one severe head-fuck for anyone trying to do anything effective with permissions delegation.

First of all i tried

https://powershellisfun.com/2022/08/22/report-on-active-directory-container-permissions-using-powershell/

A decent solution – which works perfectly in my test environment, but in the prod environment with thousands of OU’s and a stupid level of excessive custom permissions, uses approx 4GB of memory before dying consistently. So while this is definitely a good script – it just doesn’t work in this prod environment…. and that’s because of how fucked the environment is, not because the script is bad.

I moved on and found

https://github.com/canix1/ADACLScanner

Which seems to be an exceedingly nice (powershell based) AD ACL solution…. an optional GUI, plenty of configuration options and great output options – a really good solution.

For me – i needed to tick “inherited permissions”… as it is important for me to demonstrate how incredibly stupid (in case you haven’t noticed, I’m still flabbergasted that someone would do this….) it is to allocate permissions at the top level of a domain – along with having complete documentation.

 

Well done & thanks to the author – Robin Granberg – for creating a genuinely awesome tool.

 

Now comes the hard bit – removing the permissions without breaking anything.