Thursday, October 21, 2021

NEC SV9100 inMail and Exchange Online / Microsoft 365


We've utilized NEC SV9100 with inmail for voicemail for 5 years.  We also utilize Microsoft Office 365 / Exchange Online.  

Setting up the voicemail to email feature is fairly easy and there are lots of guides online to do so.  For that matter, being in IT and setting up system SMTP for scanning, alerting, etc, etc, etc is like brushing my teeth.  So, looking at the inmail settings for SMTP was enough to make me yawn, grab a cup of coffee to help stay away the boredom, and get to work.

Ten minutes later all done, tested, working... seemingly.  I had put in the smtp.office365.com port 587, TLS, username, password, blah blah blah.  In fact, I did this almost 3 or 4 years ago.  

Fast forward to yesterday.  Complaint comes in about "I've called and left a VM and no one contacted me". Of course, that triggers the CEO to call, leave a message, and then send out the email "Who got that message?  call me".  Quick looksee anddddd, well, no one got the message WTH.  I call the number, leave a message and seconds later have the message.  Call again, receive message.  Start to suspect the number the CEO called or the classic "What did the user do wrong?".  You know PEBKAC.

At this point I decide PEBKAC is wrong (since it's the CEO) and call into the VM box directly (which btw no one checks because it's an email forward only mailbox) and listen to the messages.  I hear me testing, I hear me testing again, I hear a fax machine crap message, I hear the CEO asking for someone to call him... Definitely not a PEBKAC, but rather an OHCRAP.

After a quick chat with a friend that is an NEC Certified Tech I find that I'm not the first to see this issue.  As soon as the words "inmail Office365 random issue" come out of my computer he stops me and responds with a resounding "Yesssss, we never recommend that".  

Here's the thing, directly inputting an account into SMTP settings on inmail so that it can authenticate and send works and from my experience it almost always works.  BUT when you can't lose an occasional random message from a customer, "almost" isn't good enough.

According to my friend and online searches the general accepted method is to use Gmail, local relay, or Option #2 or Option #3 of this document. (Note: I was using option #1)

How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Docs

Option #2 and Option #3 I see lots of comments online of working, but in my mind Option #1 looked like it was working to me.

In the end I decided to go the tried and true way that hasn't failed me yet IIS SMTP Relay.  Alteratively using an onsite Exchange Server, HMailServer, or other reliable method would be acceptable.  Basically, I wanted the mail to have a quick trip locally to an email Queue.  With this I can even write a Powershell script to monitor it if desired.  At the very least I'm not depending on some online authentication to occur between the NEC and Microsoft which could fail mid communication.

If you haven't setup IIS SMTP Relay before, well, it's pretty easy.  Google how to install if you don't know.  I'll give the quick config to make it work with the NEC.  I usually do this on my Print Server or another lightly used server.  Note that it does require installation of the role IIS.

  1. Add a secondary IP address to the server (don't do this on a DC). I prefer to run each SMTP Relay on it's own dedicated IP.
  2. Create a new home directory (will be used in later step).  I usually put this in C:\Inetpub\New Name.  The "new name" I typically make named the task that this relay would be for.  IE, voicemail or NEC.
  3. Open up Internet Information Services (IIS) 6.0 Manager (of course after you've installed the required roles)
  4. Right click on the server name, New, SMTP Virtual Server

  5. Give it a name.  I like to name them the task followed by - and the last octet of the ip address assigned in step 1.  Example: NEC - .44
  6. Select the IP assigned to the server in Step 1
  7. Select the Home directly we created in Step 2
  8. Enter a domain name.  I typically make this the servers FQDN.  DO NOT make it the domain name of the email that these are going to.  For instance, if the account you're emailing this to is voicemail@contoso.com then you would not want to enter contoso.com or the emails will go into the "drop" folder because it's a "local" address.  In my case the FQDN is different than the email domain so I enter FQDN :)  If your emails are going to the Drop folder (more on this in a minute) then check this.
  9. OK and you'll be presented with a new pretty SMTP relay

  10. Right click on the "NEC - .45" / virtual server and select properties
  11. Ensure "Limit number of connects to" is unchecked
  12. On Access tab, click Relay, Only the list of below, Add the NEC ip address, and I uncheck the "Allow all computers which...."
  13. Messages tab.  I change the limit message size and session size to 20480 (ie 20MB).
  14. Delivery tab, I change the expiration timeout to 4 days.  
    1. Outbound security.  This will depend somewhat on where it's going, but in my case I require authentication.  This will mostly depend on how you want to setup your SMTP Relay server using that previous link in my post.  As you can see, we're moving the Microsoft Option 1, 2 or 3 to here.  So the SMTP Relay is the one authenticating with Exchange online instead of the NEC.
      1. So, I change this to Basic Auth, enter the username of my Voicemail account, password
      2. Check the TLS Encyrption option
    2. Outbound Connections, change TCP Port to 587
    3. Advanced, change the Smart Host to smtp.office365.com
    4. Hit OK to exit out of the properties.
  15. Restart the Simple Mail Transport Protocol service (not sure if this is required)
  16. Now we test it.
  17. Make a file on the desktop of the server or somewhere named Test email.  Remove the file extension from it so that it's extensionless. 
  18. Open the file with Notepad or Notepad++
  19. Enter the following 4 lines.  Notice there are no spaces
    1. To:myemail@contoso.com
    2. From:Voicemail@contoso.com
      1. If you're using Option 1 from MS then the email address entered must match EXACTLY the account you're using to send Voicemail.
      2. Option 2 and 3 it must match any email address in your Exchange online environment. (so it can be a dist list), but note that means Step 14 Outbound security will be different as well. (maybe I'll change mine and update this post at a later date)
    3. Subject:Test
    4. Test Test (this is line 4 which is the message body)

  20. Save the file
  21. Create a copy of the file
  22. Open up file explorer to C:\inetpub\voicemail\pickup and drag and drop the copy you just made into the folder.
  23. It will instantly disappear.
  24. Go to the C:\inetpub\voicemail\drop and badmail directories to see if it's there (hopefully not).  If not then you probably got the email.
  25. If it's in Queue then something doesn't match up properly and it's gone into retry mode.  This could be that the credentials are wrong, no path out, you didn't setup Office 365 properly, etc.  Basically, it can't deliver to Office 365.  If you wait long enough (4 days) it will eventually move to badmail.
  26. If it's in badmail, then most likely issue is the From email address doesn't match up properly and it was rejected.  
  27. If it's in Drop, then from my experience this typically means I forgot my own advice and made the smtp virtual server domain the same as my email domain.  To fix this expand the tree, and in the right windows double click and change the domain.



So what was the point of this post?  This is all over the googles if you search for it...  I intend for this to be one more post that shows on the googles when people like me search to setup inmail with office365 so that others hopefully don't run into the random missing voicemail when all appears to be working OHCRAP moment.  My failure is online so hopefully you don't have this failure.

Have a better option?  Post it! 

Wednesday, October 20, 2021

IIS 7 SSL Cert - There was an error while performing this operation

It was that exciting time of year again, SSL Cert renewal time!  

I say exciting, because it never fails that when Cert renewal times comes up I hit my head against some issue (I suspect it's the exact same issue year after year and I just don't remember).

This time changing the cert in IIS 7 I'm greeted with "There was an error while performing this operation. Details: A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)

It should be noted that when this occurred the site went down!  I was able to select the old cert and hit okay and all was well again.  Select new cert, OK, and error with site down again.

NOTE: I have since found another way to produce this issue with it's own fix.  I have modified the below with Fix 1 and Fix 2.  You may have to do BOTH of the below as I recently discovered.

I found a lot of solutions out there and I'm sure they work, but I didn't see the easy one that worked for me.  I also found some that say the solution is that you have to have "export private key" checked when importing the certificate (note that this IS NOT NEEDED).


FIX 1: I had my certificate imported from a pfx without the option for export private key.  It was stored under Local Computer - Web Hosting (this is true of the old cert and new cert).

In the binding screen I selected the "Localhost" certificate.  Hit OK











I then immediately hit edit again.  Selected the new certificate from the drop down and hit OK.  Click Close, go to your site and verify it's using the new cert.


FIX 2: I had a new certificate that I imported via the IIS Server Certificates option.  No matter what I would continue to get the error following my directions above.  I found a post online where a commenter mentioned that they had to import from MMC rather than IIS.  Deleted the cert that I had imported via IIS.  Had cmd open so went to it and typed MMC, File - Add/Remote Snap-in - Certificates - Computer Account - OK. Expand Web Hosting - Certificates. Right click import my new cert changing file type to *.* and selecting cert.  DO NOT check the box for exportable.

Then went back to IIS and followed my FIX 1 steps.  Worked great.


No error, very minimal downtime (when localhost cert is selected). Happy happy

Now, will I remember this next year?  Or remember to check my blog notes?  Probably not.