Are you asking for code for an Internal Exchange Server w/out Outlook - or Web Mail. Because I think with Exchange you just need to access system.Net.Mail.SmtpClient and system.Net.NetworkCredential. But that being said, we tried it from our corporate headquarters and it gets squashed by IT security. A co-worker discovered a way to break through with VB NET but it relies on a third party dll.

Not sure if it would see a .NET attempt via WinBatch the same as the Postie but probably close enough...if so, as Stan noted, you will have to have your email administrator configure the server to allow the messages. By default it blocks such messages.

How do you capture an error from this sample? In samples I see there is a "try/catch". But I don't think it's applicable in WB.

try {

client.Send(message);

}

catch (Exception ex) {

Console.WriteLine("Exception caught in CreateTestMessage2(): {0}",

ex.ToString() );

}

}

You use WinBatch's built in error handling as try-catch block exception handling is a property of the language not the dotNet framework. See IntControl 73 in the Consolidated WIL Help file for details.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

One last question, does anyone have an example of sending an email via Exchange Web Service?

Apparently not. Not sure if this is what you are referring to but MSFT's Exchange Web Services has it's own managed assembly - Microsoft.Exchange.WebServices (in Microsoft.Exchange.WebServices.dll) - and I am not aware of any examples in the Tech Database. MSFT does have extensive documentation of the assembly on their MSDN Website. A quick glance does not reveal anything that you counldn't do using the WinBatch CLR hosting functionality. I guess this would be your chance to break new ground for the rest of us.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

I tried that with a simple powershell script to send a test message. It fails with the AutodiscoverUrl method again saying it is blocked as an insecure redirection. If I manually attempt to access the url

If you are talking about SMTP then I believe Jim already covered that ground. If you are talking about MSFT's EWS API, I am not at all familiar with it but it should work if used properly. MSFT has examples in their documentation that wouldn't be their if they didn't think it works.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

If you are talking about SMTP then I believe Jim already covered that ground. If you are talking about MSFT's EWS API, I am not at all familiar with it but it should work if used properly. MSFT has examples in their documentation that wouldn't be their if they didn't think it works.

Agreed. But some context is important. From my job, logged into the corporate network, I can automate emails from either my google or mindspring accounts, but not from my Outlook/Exchange given corporate security measures. The AutodiscoverUrl method I referred to in my last post has a second parameter, a delegate callback - and the WB CLR does not do delegates. But for the general purpose of this thread, below is the simple Powershell steps (which can be interpreted into WB CLR, or called directly from it)

Sounds like the issue is what I mentioned. The Server knows if you are not a "secure" client and it will block any attempt by anything other than the Exchange/Outlook client, unless explicitly permitted. I don't think it will matter what method you attempt to use.

That begs the question - what constitutes a secure client? The server has to recognize something in the exchange between client and server to permit an action. If it isn't just credentials then what is it? A user agent string? A quick reading of the documentation seems to suggest that the correct user-agent string and, of course, credentials are all that are needed. If that is the case then the it would just be a matter of getting someone with server admin privileges to add the script's user agent string to an "approved" list. Another option would be to somehow spoof the scripts user agent string so that it matched an approved user agent string.

MSFT's EWS documentation makes much of the distinction between authentication and authorization. Authentication is provided by either NTLM or OAuth. NTLM requires a domain connection and is supported by dotNet. But this is likely a different discussion.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

Agreed. But some context is important. From my job, logged into the corporate network, I can automate emails from either my google or mindspring accounts, but not from my Outlook/Exchange given corporate security measures. The AutodiscoverUrl method I referred to in my last post has a second parameter, a delegate callback - and the WB CLR does not do delegates. But for the general purpose of this thread, below is the simple Powershell steps (which can be interpreted into WB CLR, or called directly from it)

The AutodiscoverUrl method has two signatures with only one requiring a delegate so the method is usable in a WIL script.

Quote

so it really isn't that hard - if it works.

It is quite simple. Simpler than I had imaged. It should easily convert to a WIL script. A converted and tested WIL script example would make a nice addition to the Tech Database.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

enumVersion =ObjectType('Microsoft.Exchange.WebServices.Data.ExchangeVersion', some number here); Need the assembly to find version numberobjEws =ObjectCreate(' Microsoft.Exchange.WebServices.Data.ExchangeService', emumVersion)

objEws.Credentials =ObjectCreate('Microsoft.Exchange.WebServices.Data.WebCredentials', '[email address]', '[Password]')objEws.AutodiscoverUrl('[email address]')objMessage =ObjectCreate('Microsoft.Exchange.WebServices.Data.EmailMessage', objEws)objMessage.Subject ='Test is a test'objMessage.Body ='This message is being sent through EWS with WinBatch CLR hosting'objMessage.ToRecipients.Add('[recipient]')objMessage.SendAndSaveCopy()

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

"Microsoft.Exchange.WebServices.Data.ExchangeVersion" so it is likely and integer value. So the version passed as a constructor parameter might simply be the number 7 except that is is cast as the enumeration "Microsoft.Exchange.WebServices.Data.ExchangeVersion" so that the CLR knows which constructor to call. So an alternative may be the following:

First, an apology for getting sloppy with regard to the enumeration. I know better but was trying to do too many things as once.

It appears that the "Body" method is actually a class object. So it needs to be constructed somehow. Maybe

Code: Winbatch

objBody =ObjectCreate('Microsoft.Exchange.WebServices.Data.MessageBody', 'This message is being sent through EWS with WinBatch CLR hosting')objMessage.Body = objBody

It is just a shot in the dark but it might work. If it doesn't, it may be because the name space isn't quit right or the constructor parameter needs to be typed using ObjectClrType. For whatever reasons the CLR is a bit inconsistent about these things.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates

Thanks for the in-depth comments, answers and samples. We have an application sitting at client sites that is capable of sending a report email via SMTP or Exchange Web Services. Whoever developed the app, did not add a button to send a test email. Since the app was built on .net my goal was to enhance my existing WB script to send a test email via SMTP or Exchange web services.

I am taking the time to tinker with this. I am using the W18531 article as a beginer testing script. I have insalled the redistibutable Microsoft Exchange dlls. Version 2.1. I keep getting a 1261 stop message, oEws.AutodiscoverUrl(cEmail). It seems to me their is supposed to be some referal that needs to take place. I have included a screen shot of the extended error message as well. Can someone tell me what else I need to do? I am specifically testing this agianst an customer using micorosofts hosted exchange, office365.

I am sorry to keep posting for help, but I am not a programer by trade and a little blind to the hosted 365 environment. Thanks all!

You can't use delegates with WinBatch CLR hosting so that is not an option. Even if you could, it may not fix the problem anyway. The AutodiscoverUrl method is using your local DNS server to obtain the IP address of the URL in question. Once it gets the IP address it does whatever it is going to do using the HTTP or HTTPS protocol. It could be that in your case the default is to use the HTTP protocol and the server is redirecting the request to the HTTPS protocol. That redirection may be what is causing the problem but it is just a guess.

Unfortunately, I do not have access to an Exchange server that supports EWS and do not have experience with EWS so I can't test anything nor have any hope of sounding knowledgeable. Several articles on various sites discuss problems with the AutodiscoverUrl method and setting up a proper URL so Google may be your best bet. Here is but one of many that turned up with a simple search for the method name:

You didn't say which line is producing the error but the error is likely the result of not providing parameter type information for to one of the class constructors. You need to provide type information because constructors are often overloaded and the CLR uses type information to create a constructor (or method) signature. It then matches the signature to the correct constructor. You would do well to look up the documentation for the classes you want to use on MSFT's website and then use the ObjectClrType function to create typed parameter values to pass to whichever constructor. There are examples show how to use the ObjectClrType function in the dotNet section of the Tech Support Database.

Logged

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." - Bill Gates