I have a Windows 2003 Server box with Excel 2010 installed, upon which I am unable to create new or execute existing macros in spreadsheets. Note: this machine is in a Windows Domain (and I am not getting much help from the network folks here.)
I can and have edited the macro security levels within Excel (File, Options, Trust Center, Macro Settings --> Enable All Macros) but despite this, when I try to:
Open a spreadsheet with macros, I get an exception "Excel found unreadable content...." which goes on to refer to the VBA macros within the spreadsheet
Create a new macro in a brand new spreadsheet created on this machine, all the toolbar buttons providing access to the VBA editor are disabled.
Could this be a Group Policy setting that allows me to edit the macro security settings, but overrides these settings and prevents me from actually creating, editing, or executing VBA macros? (If so, does anyone happen to know which group policy setting I should be looking for?)
I've run rsop.msc (Resultant Set of Policy) on the machine and looked through every single thing under both Computer Configuration and User Configuration, but I don't see anything related to Excel (or Office) Security/Macros.
In this case, the problem was that Visual Basic for Applications hadn't been installed when Excel itself was installed.
(As usual, Microsoft could do a much better job of alerting the user to this unusual configuration, but what can you do.)
Related
I’ve done a LOT of googling about this and haven’t found anything specific to this situation. Apologies if I missed it.
I have a .xlsm workbook that has a few macros—-one to refresh connections to a Microsoft Access Database, one to refresh pivots, and one to save it to multiple locations.
When I open the file, I get the standard yellow security bar that some active content has been disabled—-but it used to just say ‘macros have been disabled’. When I check the macros, they are there.
BUT when I hit ‘enable’, there’s 2 issues:
it doesn’t enable anything and I have to go to the Trust Center to enable both Macros and External Data Connections. Before yesterday, I never had to do that.
Once I enable macros and external data in the Trust Center, suddenly I get an alert that VBA “can’t find a project or library” and all my macros are now gone.
When I reload the workbook, we’re back to where I started. I have one other workbook with this issue. The other 5 or 6 macro-enabled workbooks do not have this issue.
The issue with these docs persists across 2 other colleagues’ remote laptops. However, when I remote into the office and access the same files in the same folder using VMWare to remote into an office PC environment, they work just fine.
I have tried accessing Tools>References in VBA—-nothing happens when I click ‘References’. I have restarted. I have emailed the files from the VMWare environment to myself, and they don’t work. I have enabled all macros and data connections by selecting those radio buttons, but still have VBA throwing that error and my macros disappearing until I reopen the file.
I truly don’t understand. Can somehow the files be corrupted only when I access them from home? Is there any fix?
I have been working with this excel macro since April 23rd. Recently it has stopped showing up even though it is showing installed. Any ideas?
What I have already tried:
I have checked the trust center to add the folder I have the macro stored in but it is currently stored on an internal network drive that can not be added to the trust center.
I have also moved the macro to the default directory for Macros. It still will not load in.
When I just drag the macro .xla file into Excel it will pick it up and start showing in the VBA IDE, but only if the file I drag in is stored on the default directory.
Excel Macros installed:
Excel Options
Add-ins
Excel VBA IDE not showing the macros as well as not showing in the ribbon:
Add-ins tab not showing add-ins
Missing from VBA IDE
I am not certain if this applies to your case, but this is what worked for me with the following set up:
- Using Windows
- Add-in stored on the network drive
My problem was that after I installed an add-in it would show up (both IDE and as a custom ribbon), but after I closed Excel and reopened it the add-in would fail to load (no ribbon, no IDE).
First step to fix this is to add a trusted location in Excel settings:
Trust Center -> Trusted Locations
You may need to select [Allow Trusted Locations on my network] before adding a location.
You can add just one folder, or, if it is appropriate, you can even add the whole network drive.
You may want to select [Subfolders in this location are also trusted]
The second step was far from obvious to me. I also needed to add network folder as a trusted location in Internet Explorer of all things:
Settings -> Internet Options -> Security -> Intranet -> Sites -> Advanced
Then you need to add the folder path to the network folder that contains the add-in.
After completing both steps and reopening Excel add-ins in the network folder started to appear both in IDE and as a custom ribbon. These two steps were necessary part of installation for every user.
If you are using multiple add-ins you may want to consider using one network folder for them. You can also take a look at this question about network add-ins to see how they can be distributed in a more convenient fashion (one of the answers there is mine).
I am trying in our installer to add a macro that is available to every worksheet. What we presently do in our wix installer is (both 32-bit & 64-bit):
msOfficeApp.Workbooks.Add
msOfficeApp.Workbooks.Open (Session.Property("ExcelMacroLoc") & "AutoTagExcelMacro.xla")
msOfficeApp.Workbooks("AutoTagExcelMacro.xla").RunAutoMacros 1
...
<Property Id="ExcelMacroLoc" Value='C:\' />
<CustomAction Id="AssignExcelMacroLoc" Return="check" Execute="firstSequence" Property ='ExcelMacroLoc' Value='[INSTALLDIR]'>
</CustomAction>
This works sometimes, but not always. Oftentimes we get some or all of the below. What is the best way to tell Excel where this VBA script is and that it's ok to use in any worksheet?
I think the issues/questions are:
Is there anything in this macro (AutoTagExcelMacro.xla) that needs to change (written in 2000)?
Should the file's extension be changed to .xlam? And does that require any other changes?
How do I digitally sign the xla file?
How do I figure out where Excel is installed (to know where to install the macro)?
How do I determine the bitness of Excel (GetBinaryType does not work).
Is there anything else I need to do besides copy the xla file to the appropriate folder?
Also asked on MSDN (I'll post any answer from there here).
" #ProfoundlyOblivious Could you please post an answer telling us how to do each part best - digitally signing, trusted location, etc. and what/where we should tell people to look for macros being disabled? – David Thielen "
Disclosure: I am not an expert in software deployment, my knowledge is limited to the obstacles I encountered sharing my VBA solutions among peers on IT managed networks.
Note: The dialog boxes in your post do not all originate from the same cause. The first relates to security and the others to file availability.
Security
Macros have been, and still are, used in the development and circulating of malicious software. As a result macros are disabled by default and require user interaction to run.
Macro Security Settings
Macros are enabled through the Trust Center, which is accessed through the file menu. These settings are independent for each Office application and some applications may have additional options involving the suppression of a dialog box. Such as Excel where all macros may be disaabled without notification or all macros may be disaabled with notification. There are three basic settings for all Office applications summarized as:
Disable all macros
Disable all unsigned macros
Enable all macros (Not Recommended)
I strongly recommend that one does not enable all macros. It may achieve a desired result but I believe the risk is far too great to warrant the consideration.
Digitally Signed Macros
A digitally signed macro in and of itself simply means the underlying code has not been changed by anyone since last saved by the signer. If the signer's certificate is installed on a computer as a trusted publisher then macros signed with that certificate can run without notification under the requisite macro security setting.
In corporate environments, IT may retain a library of certificates and there may be an established procedure for an internal developer to submit a project for wider circulation, whereafter IT signs the project so it can be run with minimal intervention.
In my experience however, I have found many companies do not have an SOP for this process or that the process is prohibitively onerous. At such times, I turn to self-signed certificates. A self-signed certificate if miraculous for personal development because it provides ample flexibility without incurring the risk if allowing unsigned code to run. The problem, of course, then comes with sharing your code because the recipient will not have your certificate installed. They could install my certificate but my personal preference is that I send an unsigned project and they create a certificate and sign the project themselves. This is an easy step-by-step process that requires no skill beyond the ability to follow instructions.
Trusted Location
A document saved in a trusted location can run macros without notifications. Trusted locations are added in the Trust Center.
By default, XLStart is a trusted location
File Availability
When Excel is opened, it will try to refresh links to other data sources and add-ins. Those files must be open for a successful refresh and a dialog box will appear if the refresh fails.
Based on little more than experience and deduction, I believe this message is often semi-erroneous and driven by either the lack of a time out timer or too short of one. I have tested this with a simple worksheet and a simple add-in. The message pops saying the link could not be updated but it was open and updated by the time I manually check the status of the connection.
In other words, the dialog box was an iritation that served no value.
There is an option that suposedly offers some control over the "Links Could Not Be Updated" window with options along the lines of:
Update links and notify
Update links and do not notify
I have found these settings unreliable and prone to resets from crashes and updates.
To the best of my knowledge, the most assured way if avoiding this type of warning is to install the add-in after Excel is stable and uninstall the add-in before Excel closes. Of course this comes with it's on set of problems including a user perceivable slower loading time.
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
Do any of you have advice on methods for deploying an office VSTO addin, especially Excel, that makes it easy to update and deploy the document as well as the addin.
I have a document level addin for Excel 2010 that I created using VSTO. I currently deploy it using click once. However, this has a few problems. The first problem is that I publish it to ftp then users install it from my website. Since the document and addin are downloaded from the internet, I obviously have trouble getting proper permission for the addin to run and the document to be trusted. Currently I just have users manually adjust permissions and grant access when the solution is installed. That part works and is fine, but if any of you have suggestions on how to automate this that would be great.
The second problem, the main one I am wanting help with in this post, is deploying updates. I generally like using clickonce because of its ease of installation and automatic update features. The solutions I develop are used in rapidly growing fast changing companies, which means I am often making updates. Click once makes it easy enough to update the "code" or addin itself. I just have it automatically check for updates when it is started, and if there are updates it will prompt the user to download them. But what about the document? My solution doesn't only include the code. It also includes the highly customized Excel workbook.
When the solution is initially installed a copy of the workbook is just downloaded to the local computer. But what about after it is deployed to dozens of computers? Does a document level change (adding a column for example) mean going to each computer and downloading the updated workbook manually?
Surely there is a better way to automatically deploy updated versions of the workbook. Any suggestions?
Here are a few ideas I thought of:
Use some installer other than clickonce. Any suggestion on one that allows easy automatic updates?
Somehow package the workbook as an application resource. I have actually done this in some situations, but not in cases where the document itself included a VSTO addin.
Related to the previous idea. Make a "wrapper" project that includes the workbook & VSTO addin. Then the addin would be launched by clicking on a regular icon on the desktop, which would download the workbook (if an update was needed) then open it in Excel. I would prefer that method of launch over simply opening the workbook anyway.
Note: No user data needs to be preserved in the Workbook when an update is done. The old version could simply be overwritten by the new one. The workbook gets all its data from an SQL server.
You could use a Visual Studio Setup Project which leverages Windows Installer. See this deployment walkthrough guide on using VSTO 4.0.
In Visual Studio 2012, support for Setup Projects is being deprecated in favor of InstallShield LE which is another alternative.