I am currently having problems with the on-send feature on some desktop clients. I have implemented an addin but for some desktop clients emails are blocked from being sent. The email hangs and does not get sent. Is there a way to use on-send by disable for desktop clients. Can i do this in the manifest file or in powershell? Is it even possible to disable on-send for specific platforms. I want to configure my addin to never block emails. I suspect emails are blocked because event.completed() close as expected on some Desktop clients.
This is a new thing since the on-send never worked on desktop clients before. Now that it does...i have to deal with this bug somehow
There is no way to disable an add-in for just desktop clients. It is either enabled for all Win32, Mac and OWA, or off for all. This is true of all add-ins not just OnSend. Though previously this feature was not enabled for Desktop clients, it now is.
Note to unblock e-mails you should be calling event.completed({allowEvent:true}); (or false) to block e-mails. See: https://learn.microsoft.com/en-us/javascript/api/office/office.addincommands.event?view=word-js-preview
What is your scenario that you need to disable this for Desktop but NOT OWA?
You could also detect what platform you are on an change behavior of your add-in as necessary.
But the event.completed({allowEvent:true}); also have problem.
For example:
If I install a com app on Outlook then install an on-send add-in.
The problem is, if they both have simultaneous response on-send event. It will stack in an infinite loop.
As an add-in developer, the root cause looks like, event.completed({allowEvent:true}) not only end add-in but also send an 'send' event out. This will trigger a non self sending event response.
Related
I developed an add-in with a MessageComposeCommandSurface extension point.
It appears, is activated and works on outlook.office.com but with windows desktop client, Outlook 2016 (version 16.0.8625.2121), the button appears in compose mode but stays gray and it is not clickable.
I tested the command-demo-addin mentioned in Microsoft Docs and published on Github with the same result. Similarly, as shown on screenshot, it is impossible to click and launch the add-in which seems unactivated.
The COMPOSE buttons are disabled in the following instances:
1) The Item is in a public folder.
2) The Item is in Junk, Outbox (not drafts), or Sync Issues.
3) The item is "secure". DRM, or S-MIME encrypted. (older versions of Outlook also do not support S-MIME signed)
4) Outlook is offline.
In the situation where Read Mode add-ins are working, but Compose does NOT it is almost always #3. Usually the user will have on the option to always DRM / S-MIME their outgoing messages.
Update with image of security settings:
If Com Add-ins load a Custom Form this can also affect add-ins:
Checking Com Add-ins:
Note that outlook actually ships with some add-ins and a lot of com-addins work fine with Web Add-ins. It's only when Com Add-ins override the default new mail form (or other forms) that they can interfere with Web Add-ins.
Some COM add-ins will NOT use Custom Form, but will access the parent folder (item.Parent) and there is currently a bug that disable's Web Add-ins when a COM Add-in or VBA script does this.
File->Options->Add-Ins-> "Go" (next to manage add-ins)
If you have an antivirus instaled like avast, try to disable the addin of this and then try to open your compose mail window.
When I try to run Outlook via Interop using the profile name it opens a dialog for the password. This script is running from Windows Task Scheduler Task. Does it use the admin account when running these tasks? The profile been made and my email account is the only one loaded in here.
The Always prompt for login credentials is unchecked for the account listed in the profile.
This is a network computer in domain. Outlook 2010.
Profile Switch(link):
Process.Start("Outlook", "/profile profilename")
'logs in with a prompt for the password
How can I pass the password in code and avoid the dialog?
Alternatively, I have a macro that does what I need, but I have not been able to get it to run when the profile loads. This would solve the problem as well. Macros enabled is checked in the Trust Center.
Thanks
First, you need to run both application under the same security context to be able to automate one from another.
This app is being launched from Windows Task Scheduler
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 workaround, you may consider usign a low-level API on which Outlook is based on - Extended MAPI. Or any third-party wrapper around that API such as Redemption.
I have an outlook addin which is located on the network drive for all users to use.
When network fails may it be because of a cable that plugged out, or a system issue, if at that moment, the user launches Outlook (when no network is available), outlook automatically ticks off the addin out of usage.
For as long as the user doesn't enable it back, the add-in will not load. ever. you can close outlook , reopen it, it won't load the addin if it failed to find the .VSTO file once when outlook started.
Setting the registry value to never disable the addin, isn't effective here, because the addin is not realy disabled, its only been shut off and waiting to be reactivated manually.
I would like it to stop being shut off, or at least auto-enable it self when network is accessible. can this be accomplished without an 3rd party exe running in the background ?
Put the addin locally to each computer and equip those computers with simple script which runs on user logon and copies the addin from its network location to local directory. This will keep your addin both updated and always available.
In case if the network is inaccessible, it is the script (invisible to user), which will fail, not the Outlook. This makes a difference :)
Of course, besides the initial launch of the script, there are also possibilities to re-run it on regular basis (once a day?) when a user is logged on. This will be be effective only when Outlook is not running at the moment, otherwise the addin DLL cannot be overwritten.
It is not a good idea run from a network drive. Why not copy the dll locally when you install your addin?
Why not install locally and then write code to check the network location? If the network is available, compare the remote dll to the local one. If they are different, copy the new dll to the local machine, then adjust the registry entries for that addin. Then display a message to the user to restart the application.
I have a 32bit legacy VB6 application that uses a COM component to automate Outlook to send an email. The requirement is that the email needs to appear in the Sent Items folder in Outlook. To make matters worse the application is not allowed to pop up the usual security, warning or confirmation messages.
This application was working without any issues until 64bit Office came along. There is no way for a 32bit process to automate a 64bit Outlook.
The idea I came up with was the following:
Swap out the COM component with a
.NET WCF Client that runs in the CCW
(.NET pretending to be COM)
This COM component calls a WCF
service running as a 64bit process, using the netTcpBinding.
The WCF service (running as LOCAL SYSTEM) then launches a 64bit
Console application as the user, and
makes use of the Extended MAPI
library to send the email.
The reason for the 3rd step is two-fold:
MAPI will ask for confirmation if
you tell it to send an email.
Extended MAPI does not. This meant
we had to compile a C++ Extended
MAPI library with the correct 64bit
header files from Microsoft, and "invoke"
that from our .NET code.
Impersonating (term used loosely) the user in WCF
results in the incorrect Registry
hive loading. In other words when
Extended MAPI tries to load the
profile from HKCU it fails. This
meant we had to launch a new process to essentially "RunAs" the correct user.
This all actually works in practice, but I need some explanations for the following:
If I run the Console application with all the information it needs in command line parameters, MAPI fails to login. However, if I compile this same code as a Windows application with 1 Form, with exactly the same code in the form's OnLoad( ) method, then it succeeds. Can anyone explain why?
To run the "WinForms" application from the WCF service as the currently logged on user (not LOCAL SYSTEM) I did the following to get the correct token:
sessionID = (int)WTSGetActiveConsoleSessionId();
ret = WTSQueryUserToken(sessionID, out currentToken);
Is there any way around this? Surely it would be better to use WCF's built-in impersonation.
There is no way for a 32bit process to automate a 64bit Outlook
Not entirely true, if you can create the COM object out of process it will work. Options include creating a small .exe that services as a factory for your COM objects.
See this SO post
I'm using wix3 to build a setup file, I would like to know whether the outlook is running during the installation. If the outlook is still running, the setup should notify the users to close it or have to reboot after the installation.
I noticed that there is a feature can send a message to close the outlook directly, but that's not very friendly. I would like to knwo whether the FileInUse dialog can be called in such situation.
Thanks.