The docs say:
By default, on-send functionality is disabled. Administrators can enable on-send by running Exchange Online PowerShell cmdlets.
This does not appear to be true for Office 365. Our on-send functionality is working fine without having had to enable anything. We've tried this with multiple (new) tenants. Are the docs outdated?
On-send functionality is disabled by default on JSVVM, but enabled by default on OWA React. That means, it is enabled by default for Office 365.
The Documentation should be updated to be more specific.
Related
We run some custom add-ins in Outlook application and occasionally find that the Outlook application disables them; I then have to manually go to the application settings and re-enable them on each users PC. We are running Microsoft Office 365 click to run applications. I have tried the following but nothing seem to work 100% of the time.
I have tried setting the "AddinList/ProgID" REG key to 1 (always enabled) as described here - https://learn.microsoft.com/en-us/office/vba/outlook/concepts/getting-started/support-for-keeping-add-ins-enabled.
I have also tried setting a number of registry key combinations as described here - https://www.konnectemail.com/prevent-outlook-add-in-from-getting-disabled
Is there a specific way to tell the office application to NEVER disable a particular add-in regardless of the Office version?
The documentation says:
On-send functionality is only supported for user mailboxes in Outlook on the web, Windows, and Mac. The functionality is not currently supported for the following mailbox types and modes.
Shared mailboxes
We see that on-send does work with shared mailboxes. Has something changed recently to make the docs inaccurate?
ItemSend should work with the SupportsSharedFolders tag: https://learn.microsoft.com/en-us/office/dev/add-ins/reference/manifest/supportssharedfolders
But it should not work without that feature. The Documentation should be updated to be more clear.
I have deployed a light weight add-on through extension manager for SAP 9.2, in the server the add-on is installed and works as expected. But in client machine, the add-on is not getting installed.
I tried all of these,
Un-assign and re-assign the add-on to the company
Check the SAP
Client agent is running
Remove the AddOnsLocalRegistration.sbo and AddOnsInstall.sbo files
Check company/server
Set add-on as mandatory
We have 2 add-on's that uses ARD instead of extensions to register and these add-on's are installing correctly without any issues.
I have even tried to copy the add-on folder and the AddOnsLocalRegistration.sbo from server to local and surprisingly found that SAP is uninstalling the addon when i log in. Users are using SSO to sign in to SAP B1.
This is an issue in SAP. Note: 2467361
Symptom
In your SAP Business One application, you have enabled single sign-on and you have assigned several lightweight add-ons using the Extension Manager. After you bind a SAP Business One user with a Microsoft Windows account, the lightweight add-ons disappear from the Add-On Manager.
Cause
Application error
Make sure that the AddOns folder has full rights for everyone to read/write.
Change this under Properties->Security->Edit
C:\Program Files (x86)\SAP\SAP Business One\AddOns
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 am developing a vsto COM Add-in with form region for Outlook. It works fine. However, I am facing problems disabling the Add-in in Outlook 2010.
From the File Menu > Options > Add-ins > COM Addins (dropdown) , I am unchecking my Add-in. But when I restart Outlook, the add-in is enabled again. If I check in the COM Addins list, its again enabled. Even the registry entries indicate that the Add-in is enabled again. Does anyone know what might have caused this? Can enabling and disabling be handled in my code, or will it be taken care by Outlook itself.?
If the addin is installed in both HKCU and HKLM, make sure you disable it in the HKLM registry hive.
Typically when any changes made in the host application run under regular user privileges are written to the HKCU hive. For example, if the add-in is registed in the HKLM hive any changes in the UI are written to the HKCU hive due to the fact that the host application was not launched with admin privileges (which is required for writing to the HKLM hive). See Registry Entries for Application-Level Add-Ins for more information.
P.S. Try to run Outlook with admin privileges and see the difference.
As it turns out, its is a bug in Office 2010 Professional. To disable the add-in, you need to run Outlook as an admin, and then disable the add-in.