Azure AD signin – change from UPN to email address

Our users UPN (User Principal Name) differs from their email address.  When syncing AD with Azure AD Connect it pulls over the users UPN and defaults to their login address.  The company wants the login to be the users email address, and not their UPN.

The following steps are to add the email address to the AD Connect sync to Azure AD, and then to allow the email address to be used as the login instead of the UPN.

Uninstall Azure AD Connect and all components in the wizard.

Reinstall Azure AD Connect and select ‘mail’ as the ‘USER PRINCIPAL NAME’

EternalBlue Exploit used to Deliver Remote Access Trojans

EternalBlue Exploit Actively Used to Deliver Remote Access Trojans

On May 16th we started experiencing mail flow issues on our unsupported Exchange 2007 environment hosted on Server 2003 OS’s.  Mail was coming in over SMTP and being delivered to users as normal, however internal emails, and outgoing emails appeared to be going into $null.  I could not see them in any Exchange logs, there was no trace of what was happening to them.

After some investigating, another engineer found two ports were blocked, 135 and 445 or RPC and MS Directory Services.  The Windows firewall on all machines is disabled by default so we double checked that and moved on.  First stop, our antivirus, we disabled and then completely uninstalled on what servers still had it running, wait how was AV missing on these servers?  Next we checked our other fancy AI machine learning super advanced security application, Cylance, that was missing as well… hmm…

The workday had ended and myself and the other engineer were at home for the evening, i was VPN’ed in, determined to find what was blocking this traffic.  I had seen a few event logs referencing IPsec and a GUID but I hadnt thought much on those, i did a quick google search on IPsec rules and SErver 2003, loaded up the IPsec Management Console and noticed there was a new rule created, last modified a few hours earlier, the rule was simply called ‘win’.  Upon entering the rule I noticed there was a deny list, and sure enough, ports 135 and 445 were listed, unassigned the win IPsec rule, and mailflow started up again.  I checked the 3 other 2003 servers, same rule, unassigned, mailflow issues resolved.

Also during investigation, in event logs, i found an MSI trying to install when the other admins were logging in. was the name, and I found this in registry, scheduled tasks, and startup.


I was tasked with looking into setting up a PKI for an organization.  I have not worked with PKI much at all, so I spent an hour or so and put together a quick document.  The organization was looking to utilize a PKI to keep mobile devices from connecting to the corporate WLAN.



I installed Exchange 2016 in a test environment and used a SSL cert from for securing OWA. Upon loading OWA in Firefox I got the following error:


Firefox will throw this error when its using an inferior encryption protocol such as SSL 3.0, TLS 1.0, TLS 1.1

I wanted to force the server and clients to use TLS 1.2 for best security. The following article below from Exchange Team Blog goes into more detail and the required changes to get it working. I did have to reboot the Exchange server after making the registry changes, an IIS reset was not enough.

Exchange TLS & SSL Best Practices

HP finally admits Firmware Update in Intelligent Provisioning is broke

I have been working with HP servers for 10+ years.  The hardware is generally good, however with anything HP, their website, software, and support is terrible.

I have a few new DL380p Gen8’s i am re-provisioning and booted into Intelligent Provisioning and wanted to update all the firmware.  Now I am aware of HP SPP, but why have Intelligent Provisioning if i have to download a 6GB SPP ISO, copy it to DVD, and go through that entire process.

So I opened a ticket with HP, they said it wasnt a problem, 3 weeks later they emailed me asking if there was anything else and if i could close it.  Well i responded, and at the bottom it gave me several other emails that i decided to CC on the email.

Well someone from HP actually called, and i spoke with them several times on the phone, after frustratingly explaining many times the issue, and asking if they are actually trying this on their servers, and them not understanding how their own products work, they went and spoke with another team.  Finally after 5+ attempts they finally emailed me the following:

“Yes, you are correct. When we click on the Firmware update button, it tries to connect ““(No information about the Port number being used here).
Now the concern is that the FTP location(Which is like a Repository of all the files) is no longer available after the HP separation. 
The concerned Team is working on it, however we don’t have an ETA for the same. The only workaround is to use SPP as in an iso or FTP to update files accordingly. “

I replied back:

“OK, please let me know when the Firmware Update button in Intelligent Provisioning is working again

I would send out an email to your customers as well that you are aware of the issue and working on fixing it, since this probably affects everyone with an HP Gen8 or Gen9, customers would appreciate that info as they are often frustrated with HP things not working correctly, especially your website.”

New users not showing up in OAB but show in GAL in OWA

Event ID 9320
OALGen could not generate full details for some entries in the offline address list for address

Get-OfflineAddressBook – Identity “Default OAB” | fl
GUID: 2e91c924-5590-4013-94a2-0dc08fe9285e

I checked the OAB folder on the Generation Server, and the 2 distribution servers, and noticed one of the distribution servers had files that were not modified with todays date, but the generation server did, as did one of the distribution servers.  So it appears to be a replication issue.

D:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\2e91c924-5590-4013-94a2-0dc08fe9285e

Our 2 HUB servers are set as the OAB Distribution points, but is showing files last modified 10/11/2016 while the other is today, 10/12/2016.  So there seems to be a replication issue between them.

I ran Update-FileDistrubtionService – Identity EXCH01 -Type OAB
This ran about 15 minutes and didn’t finish

On the server without the updated OAB lzx files I restarted the Microsoft Exchange File Distribution service

The lzx files last modified date then updated to today’s date.

From my Outlook i downloaded a new copy of the OAB from Send/Receive and tested by creating a new email and confirming the user missing was now available

Stollfus Tech Blog

WordPress Appliance - Powered by TurnKey Linux