I have code which will send email when done through a button click.
I have scheduled the same code to run periodically through Task Scheduler. The mail gets in draft stage.
Issue 1: if I use .Send, there is a security pop up with allow or deny options
Issue 2: to avoid the above pop up, I used .Display, wait for the application and sendkeys --> this is working when run through button click but when run through scheduler the email stays in draft stage.
Issue 1 : if I use .send in mail, it ask for a security pop up with allow or deny option
This is a standard security prompt in Outlook. "Security" in this context refers to the so-called "object model guard" that triggers security prompts and blocks access to certain features in an effort to prevent malicious programs from harvesting email addresses from Outlook data and using Outlook to propagate viruses and spam. These prompts cannot simply be turned off, except in Outlook 2007 with an anti-virus application running. This page discusses strategies for avoiding security prompts.
Issue 2 : to avoid the above pop up, I have used .display, wait for the application and sendkeys -->
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a possible workaround, you may use a low-level API which doesn't trigger security prompts - Extended MAPI. Or just any wrappers around this API such as Redemption. It allows bridging both issues.
Related
In our organisation a problem occurs when saving Excel files.
Whenever we close a file there is a 50/50 chance that it saves in the location it was already in, but the other times it saves where another file was last saved.
We are all working on a Terminal Server (Windows 2019) using Office 2019.
Did anyone else stumble upon this as well? And perhaps found a solution?
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
I'd suggest using the Open XML SDK instead if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office for more information.
I have a Windows service filling cells in an Excel Workbook via OLE Automation.
The save process is not working, the file is never saved. But when done in a GUI app, the save process works.
The service user is an administrator account. I suspect the interaction with the Desktop.
Any idea?
Don't do this. Find another solution. Microsoft does not support or recommend OLE automation of Office software from anywhere but a workstation desktop session. I can't paraphrase any better than what they say directly, so here's the advice (link above goes into more detail) :
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
If you need your service to store data, a database is probably a good choice. Any users that require the data in an excel spreadsheet could populate their documents from the database. You could even set up template documents to do this automatically.
I had the same problem, run a Delphi software as service, with an administrator user and it gave to me a lot of errors in the read/write process like SaveAs method of Workbook class failed
The solution for read/save was create both folders below:
C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile\
There isn't much sense at all, but it worked.
I am currently using Microsoft Outlook 2013 and Access 2013. When I upgraded to 2013, there was a security update that doesn't allow the SendObject method in Visual Basic. It's not allowing me to send emails from my program in Access.
Is there a way around this security update?
There was no such security updates. Most probably you are talking about the standard security prompt in Outlook. See Outlook "Object Model Guard" Security Issues for Developers for possible options.
I'd recommend using the Outlook Security Manager component which allows to supress such prompts or avoid errors in the code.
Is it posible to create outlook meeting on Sharepoint page behalf on current sharepoint user?
I try to create meeting by button click with next code
Application oApp = new Microsoft.Office.Interop.Outlook.Application();
AppointmentItem appointment = (AppointmentItem)oApp.CreateItem(OlItemType.olAppointmentItem);
appointment.Start = DateTime.Now.AddHours(1);
appointment.End = DateTime.Now.AddHours(2);
appointment.Subject = "Some subject";
appointment.Body = "Some body";
appointment.Recipients.Add("user1#somemail.com");
appointment.Recipients.Add("user2#somemail.com");
appointment.Save();
But i get this error, on calling appointment.Recipients
Operation aborted (Exception HRESULT: 0x80004004 (E_ABORT))
When i run this code in console application it works fine. Any ideas?
Thanks in advance
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
If you deal with Exchange profiles, you may consider using EWS (Exchange Web Services). See EWS Managed API, EWS, and web services in Exchange for more information.
Is there any other way to get rid of this outlook security message? "A program is trying to automatically send e-mail on your behalf ... and so on" and it gives me an option to select Yes , No & Help.
Im currently developing an outlook automation app using Ms Access. Everytime I issue Send command this message popups, I tried using SendKeys "%s" but it does not work in Access 2007.
Is there any alternative solution for this? Thanks!!
You may wish to consider Outlook Redemption
From the blurb:
Outlook Redemption works around limitations imposed by the Outlook Security Patch and Service Pack 2 of MS Office 98/2000 and Office 2002/2003/2007 (which include Security Patch) plus provides a number of objects and functions to work with properties and functionality not exposed through the Outlook object model.
Microsoft doesn't want scripts to be able to send email without the user's consent. According to KB 263084, you can do one of the following (which avoid the scriptable interface or configure the system to supress the message):
change some Exchange Server settings
use CDO
Use Extended MAPI
use a COM add-in
I don't think any of the programming solutions is particularly simple, and applying changes to Exchange might not be a solution for you (especially if your application is supposed to work with Outlook clients that aren't in an Exchange environment, of course).
You can avoid this by relaying the message directly to an SMTP server, rather than using Outlook to relay the message. The security warning is there to stop people like you from sending messages from my account without my knowledge. Although you have good intentions, what you are writing is essentially virus-like (imagine if you could do this without the security prompt - spam-heaven!)
If you don't want to use Redemption (others already adviced so I think you don't), you have another option that I can assure will be a lot more painful to implement.
Basically what you will need to do is to create an Add-In instead an external program. The Add-In is able to do whatever you want to Outlook, without getting those messages.
You can probably make the Add-In act like a simple server - do things you want by receiving commands from the outside world (in case you can't do whatever you need to do from within Outlook).
Maybe you can lift a WCF service (IPC or Inter Process Communication, that works like a shared memory between two processes).
Please note however that you will probably be better if you just use Redemption or just an Add-In.
Connecting Outlook with external process is a pain and it get's worse by the fact that the Outlook classes are not serializable. So basically you will need to do add Data Transport Objects for each and every class you need to access through your app.
Maybe if you resolve this one it will be a bit easier to implement but it is still a challenge.