Testing Outbound Email Notifications Using Telnet

Testing Outbound Email Notifications Using Telnet

  • Comments 5
  • Likes

Setting up outbound email notifications from SCSM can be a bit tricky and sometimes customers have trouble with it.  In this blog post I’ll show you a way that you can test trying to send an email via the SMTP server.  First – I’ll assume that you have already set up the SMTP notification channel in the Administration\Notifications\Channels view something like this:


One thing that people get tripped up on is that they don’t make the return email address the same as the email address of the Workflow Run As Account.  That’s got to be the same or outbound notifications won’t work.  Depending on the Authentication method you have set – Anonymous or Windows Integrated you need to make sure that your SMTP server is configured to allow that.

Here’s how you can test to see if your SMTP server is set up correctly:

0) You’ll need to have Telnet installed on your server to do this.  You can add it via the Features wizard in the Server Management console.

1) Login to the SCSM management server that will be running your workflows (by default this is the first management server you install in a management group).  Login as the Workflow Run As Account!

2) Open a cmd prompt.

3) Enter telnet <the FQDN of your SMTP server> <the port number>


4) Enter EHLO <the DNS domain name where the SMTP server is at>



If you get a successful connection you will see this:


5) Enter MAIL FROM: <the email address of the Workflow Run As Account>


6) Enter RCPT TO: <some email address you want to send to>


7) Enter DATA


8) Enter SUBJECT: <some subject you want to have> and hit Enter TWO times:


9) Enter a message body followed by Enter, then a period, then Enter again.


10: Enter QUIT

If things go well you’ll receive an email message at the recipient email address you entered above in step #6. 


If you get any error messages along the way from the SMTP server, just do a bing search for that error code and you’ll usually find lots of helpful information out there about how to configure your SMTP server correctly for that specific issue.  This approach will help you isolate whether the problem is something inside of Service Manager itself or if the SMTP server connection is not set up correctly due to permissions, network configuration, firewalls, etc.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Our Exchnage server used to catch the emails, it thought it was spam. So I had to set up a rule to let all emails in, which contain a magic word, like "scsm". Then I inserted that word in small letters to the end of each email template...

  • Hi Travis,

    You mention "Login to the SCSM management server that will be running your workflows (by default this is the first management server you install in a management group)."

    I installed a 2nd management server and it immediately started running all the workflows (or at least trying). This included the Exchange Connector.

    Is this normal behaviour when a new management server is installed?

    How do you correctly determine which server is the workflow server and how do you change it?

    With Thanks,


  • @Rob -

    No that is not expected behavior for the second management server to take over responsibility for running workflows after it is installed.

    You can see what management server is currently the workflow server by running this query in the ServiceManager database:

    SELECT BaseManagedEntity.DisplayName, ManagedType.TypeName

    FROM BaseManagedEntity, ScopedInstanceTargetClass, ManagedType


    BaseManagedEntity.BaseManagedEntityId = ScopedInstanceTargetClass.ScopedInstanceId


    ManagedType.ManagedTypeId = ScopedInstanceTargetClass.ManagedTypeId

    You can read more about this query and other information about workflow targeting here:


    You can change which workflow server is by running this query:

    EXEC p_PromoteActiveWorkflowServer ‘FQDN of your SCSM server that you want to make run the workflows’

  • @Travis,

    Thanks for confirming that, I thought I was going mad for while. I think what caused this is because we installed the 2nd server with the base (not SP1 installer). This was done because the SP1 installer asks for a product code, and ours is built into our VL download. So, we had to install from the base installer and then upgrade the new server to SP1.

  • @Rob -

    FYI There is a VL version of SP1 too.  :)