Saturday, November 7, 2020

Laggy Mouse and Jaggy Fonts

I have a 4K TV hooked up as my monitor with an older video card. Unfortunately, this video card can only output 4K at 30Hz which isn't optimal, but for my purposes is just fine. I'm not playing games that require fine tuned actions.

I recently changed my display to 1080P for an online presentation and then back to 4K. By default, 4K was running at 60Hz, however, this made the text slightly blurry because HDMI was compressing the signal. Set it down to 30Hz to fix that, but then the text was jaggy and not smooth. Also, my mouse was really laggy as I moved it around the screen.

When I changed back to 4K 30Hz, Windows 10 and the TV negotiated using HDR (High Dynamic Range) for display. Normally when Windows 10 negotiates a setting, that's preferred, but not in this case. When I disabled HDR in display settings, my fonts were smoothed properly and the mouse lagging stopped.

Monday, October 26, 2020

Convert ImmutableID to Hex for AD

To get the immutableID value from a user (should be able to do similar with Get-MSOLUser if preferred):

$id = (Get-AzureADUser -ObjectId

To convert that ID to hex for entry: 

$hex=([system.convert]::FromBase64String("$id") | ForEach-Object ToString X2) -join ' '

To view the value in $hex:


The immutable id will be a value something like: fhG+Kox7LkaYwSIf6s6UFA==

The hex for that one is: 7E 11 BE 2A 8C 7B 2E 46 98 C1 22 1F EA CE 94 14

The hex value can be entered into the ms-DS-ConsistencyGUID attribute of the user object.

And converting from objectGUID to ImmutableID:

$immutableID = [system.convert]::ToBase64String(([GUID]($u.ObjectGUID)).tobytearray())

And converting ImmutableID to GUID:  

$objectGUID = [Guid]([Convert]::FromBase64String($ImmutableID))
UPDATE: I've created a set of functions that you can use for conversions at

Wednesday, October 7, 2020

Install-Module Fails without TLS 1.2

I've run into problems with Windows Server where the Install-Module cmdlet generate errors and won't download from the PowerShell  repository on the internet. To fix this you need to enable TLS 1.2 for PowerShell.

WARNING: Unable to resolve package source ''.
PackageManagement\Install-Package : No match was found for the specified search
criteria and module name 'xxxxxxxxx'. Try Get-PSRepository to see all available 
registered module repositories.

To do this permanently for .NET 4 and up, set two registry keys for 64-bit and 32-bit .NET Framework:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319'-Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

If you need to do a quick temporary fix because you can't update the registry then use this:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

The temporary fix is only for the current PowerShell prompt.

Wednesday, July 29, 2020

Issues with Exchange 2010 and Exchange 2016 coexistence

This one is primarily notes to myself...

  • When Exchange 2016 is installed with Exchange 2010, MAPI over HTTP is enabled by default for the organization.
  • Exchange 2010 mailboxes continue to accessed via RPC.
  • Exchange 2016 mailboxes will use MAPI over HTTP
  • If Exchange 2016 mailboxes have Full Access to an Exchange 2010 mailbox then Outlook Anywhere is used to connect to that secondary mailbox.
  • If using a wildcard cert you need to set the certificate name for the EXPR outlook provider for Outlook Anywhere as msstd:*

Authentication prompts

Exchange 2010 on Windows Server 2008 R2 requires a security update for Outlook Anywhere to function properly. This is a security update from 2016 (KB3140410). It "should" already be in place, but if it's not then Outlook Anywhere will cause tons of authentication popups in Outlook.

I saw this manifest as Exchange 2016 mailboxes with a secondary mailbox on Exchange 2010 getting the popups. Only an Exchange 2016 mailbox was fine because it used only MAPI over HTTP on  Exchange 2016. Only an Exchange 2010 mailbox was fine because it used only RPC to Exchange 2010.

If the update is not in place and you don't have the opportunity to apply the update quickly, you can modify DefaultAppPool in IIS Manager to use the identity Network Service. Recycle DefaultAppPool for the the change to take effect. Recycling DefaultAppPool does not affect users.

Error message that you will likely see in RpcHTTP proxy log (C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp):

Complete=PrepareServerRequest;,WebExceptionStatus=ProtocolError;ResponseStatusCode= 401; WebException=System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at
Microsoft.Exchange.HttpProxy.RpcHttpProxyRequestHandler.c__DisplayClass1.nullb__0(); HttpException=System.Web.HttpException (0x80004005): NegotiateSecurityContext failed with for host '' with status 'InvalidToken' at Microsoft.Exchange.HttpProxy.KerberosUtilities.GenerateKerberosAuthHeader.

Win7 certificate errors

Windows 7 clients that don't have TLS 1.1 and 1.2 enabled might see a certificate error when connecting to Exchange 2016 for web services (not necessarily mailbox). To enable TLS 1.1 and 1.2 on Windows 7, you need to ensure that update KB3140245 is installed. With the update installed, you need to create additional registry entries.
The registry keys created by the quickfix utility distributed with this update by Microsoft are:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    • Create DWORD: DefaultSecureProtocols
    • Value: 0xA00
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    • Create DWORD: DefaultSecureProtocols
    • Value: 0xA00
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    • Create DWORD: SecureProtocols
    • Value: 0xA8
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
    • Create DWORD: SecureProtocols
    • Value: 0xA8
The DefaultSecureProtocols key is used by the Office Apps and the value 0xA00 designates TLS 1.1 and TLS 1.2.

The SecureProtocols key is used by Internet Explorer and the value 0xA08 designates TLS 1.0, TLS 1.1, and TLS 1.2.

Tuesday, April 14, 2020

MIS2000 Links

Using Power BI for data analytics and reporting

City of Winnipeg Software Piracy

What's wrong with this picture?

Computer system failure grounds transit system in San Francisco

Supply Chain Management Simulator

Career wisdom from IT pros

(A few) Ops Lessons We All Learn The Hard Way

Michael Geist blog (copyright and net freedom issues)

Government IT failures

Federal Government - Phoenix payroll system #1

Federal Government - Phoenix payroll system #2

More Phoenix payroll

Phoenix payroll - 3 years later and still broken

Federal Government - Gun registry


Malware distribution hosted in LED light control console

Ransomware attacks lock 2 Manitoba law firms out of computer systems

Is Huawei really a risk?

City of Saskatoon phishing

City of Ottawa victim of phishing

Stolen laptop with health data

Government of Nunavut Ransomware

Nursing Home Network Ransomware

Spear Phishing

Scammy companies

WeWork - A tech company?


Theranos timeline

Theranos - Wall Street Journal expose


What is cryptocurrency?

QuadrigaCX Cryptocurrency Exchange Shadiness

QuadrigaCX empty accounts - even more shady

Cryptoqueen: How this woman scammed the world, then vanished

Thursday, April 2, 2020

Azure AD Connect Large Object Error

A client is migrating their remaining mailboxes from on-premises Exchange to Office 365. Today they went to migrate a mailbox, but the user account wasn't replicated up to Office 365. After verifying that it was not being filtered by OU in Azure AD Connect, I checked the Synchronization Service Manager for Azure AD Connect and found an error listed for the export to the Azure AD tenant (

The error was LargeObject and when I drilled down, it had these details:
The provisioned object is too large. Trim the number of attribute values on this object.

This error is typically caused by:
  • Too many user certificates (15 max)
  • Too many SMIME certificates (15 max)
  • A thumbnail photo that is too large
  • Too many proxy addresses
This user object did not have any user certificates, SMIME certificates, or a thumbnail photo. So, let's check out the proxy addresses.

The user object had 540 addresses. After a bit more research, I found that user objects in Azure AD have a limit of 400 proxy addresses, Azure AD Connect has a limit of 333 proxy addresses.

They do have a legitimate need for this account to receive mail for all of those addresses. We implemented a workaround by creating a group for the extra addresses. We removed 300 email addresses and put them on a group where that user is the only member. Mail flow is preserved and now both the user and the group can sync. The group is hidden from address lists to avoid confusing the users.

More information:

Tuesday, January 21, 2020

Reporting Script Duration

Currently working on a migration project where the source and target environments are quite large. We have a script that queries all mailboxes in the source and matches them to a target object.

The script takes 10-12 hours to run. We're making tweaks and want to see the effect, but we're not going to watch the script to verify the time to complete.

Here's a little bit of PowerShell that you can add to any script to measure the time to complete:

 #Start of Script  
 $start = Get-Date  
 #End of script  
 $end = Get-Date  
 # Calculate elapsed time  
 # Output in format hh:mm:ss  
 Write-Host “Script run time”  
 Write-Host $($end-$start)