I've created several add-ins for PowerPoint 2010 and Excel 2010 using VBA (I don't have Visual Studio available). The add-ins work fine on thin clients using Windows 7 Enterprise SP1 32-bit and Office Professional Plus 2010 14.0.6123.5001 32-bit. On thick clients (regular PCs) with Windows 7 and Office 2010 32-bit, the add-ins will not work. Nothing happens when users try to install them; the toolbars do not appear, but there are no error messages or notification bars. The add-ins display as loaded in the add-in manager, though, and it's possible to run macros manually from the VBA editor.
I've investigated issues with security settings and digital signatures. The add-ins are digitally signed, although the add-in manager does not display the publisher information. Users are prompted to trust the publisher when attempting to install the add-ins; trusting the publisher does not make the add-ins work and does not lead to any error messages.
In the add-ins tab of the trust center, the option to "Disable notification for unsigned add-ins" is checked and grayed out on the thick clients where the add-ins do not work, and unchecked on the thin clients where they do work. When checked on the thin clients, the add-ins continue to work, so I don't think this is the problem. And both deployments use the 32-bit version of office, so it's probably not that either.
Any ideas what might be causing the problem, and how to fix it?
I was having a similar problem, and the instructions for trusting publishers recorded on this website helped me to resolve the problem:
http://www.excelguru.ca/content.php?199-Security-In-Microsoft-Office
However, for mine to work I could not use the certificate created using the selfcert.exe program that comes with Microsoft Office.
Related
I have Windows server 2016. set up rules on Outlook for specific email Subject to save attachment upon receive into specific folder and upload the attachment data into AS400 database. The rules and code is working fine but the problem is when email received the rules apply during server log off, the VBA code windows will left open. However the program is still running fine. The only problem for me is VBA code windows left open when rules trigger during Windows Server Logged off.
Keep running Outlook on the server side is not really a good idea. If you deal with Exchange profiles only you may consider developing a gateway for processing incoming emails instead. Outlook is a client-side application and designed running by a user. Here is what MS states for such scenarious:
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.
We're developing an Outlook addin that is specific and proprietary to our organisation. So we'd rather not put it on AppSource and we'd rather not put the addin source files (all the js,css etc) on a publicly accessible url even if we can keep the manifest file private.
Is there a way, through centralised admin and deployment, to distribute this Outlook addin to our staff, using Group policies, and still keep all the addin files privately hosted somewhere?
Yes, you can deploy an add-in by side-loading the add-in manifest xml file using Centralized deployment.
Yes, you can host add-in files privately but make sure the add-in host is accessible from your Outlook client.
If add-in is bound to work only when the user is connected to a particular network/VPN, it is good to educate the user that the add-in is unavailable outside the network boundary.
For on-premises and online environments that do not use the Azure AD identity service, you can deploy Outlook add-ins via the Exchange server.
Outlook add-in deployment requires Office 365, Exchange Online, or Exchange Server 2013 or later. Outlook 2013 or later.
To assign add-ins to tenants, you use the Exchange admin center to upload a manifest directly, either from a file or a URL, or add an add-in from AppSource. To assign add-ins to individual users, you must use Exchange PowerShell. For details, see Install or remove Outlook add-ins for your organization on TechNet.
Read more about possible ways in the Deploy and publish Office Add-ins article.
I am planning to develop a outlook add-in which will work with the desktop version of outlook 2010 and 2013.
Can i publish it on the online office store (https://store.office.com/) or is it that the store only allows submission of office 365 apps???
I tried looking at the store's documentation but it does not mention anything on the topic.
I have tried contacting Microsoft support but they seem to have no clue.
You can't publish COM add-ins to the Office store.
COM add-ins (like any other Windows desktop applications) can be published to the Windows store.
Office Store only accepts JS based addins. COM addins for the desktop versions of Outlook cannot be distributed though the store.
I am working on a VB.NET web forms application using VS 2013 Pro (Vr: 12.021005.1 REL) and IIS Express. After a certain number of rebuilds I'm finding that the application, despite building, times out in the browser (Chrome). The only way I have found to fix this situation is to restart Visual Studio, this obviously gets a bit tedious after a while.
I have recently switched from VS2012 working on the same application without issue. I'm also experiencing the same problem with another web forms application. What can I do to identify the cause of the problem? I've already tried disabling Browser Link and temporarily switching off the Antivirus.
EDIT
When the application times out (usually after a rebuild or refresh) I am unable to stop the site from the system tray. I am however able to stop other sites in the solution, it's as if Visual Studio is locking this action. Killing VS instantly stops the site.
We have Team Foundation Server 2010 installed on a domain server with Visual Studio 2010 installed on the client side connected to the domain. All works well.
We then installed TFS Powertools 2010 so that we could use the TFS facilities integrated with Windows Explorer. This doesn't seem to work - the Team Foundation Server sub menu which is present in the context menu has only one entry - "Reconnect to server". When this is selected an error is returned saying "Unable to connect to Team Foundation Server".
I would have expected a dialogue box requesting credentials to be input but this does not happen. Does anyone know where these credentials are stored or some other work around? I've seen similar questions but no definitive answer.
Thanks in advance
You can store the credentials in the Windows Credentials Manager (Windows 7). You can find that in the control panel.