How do I allow access to Office applications automation object from standard users in Windows 10? - excel

I have several automation scripts that I wrote to move information in and out of Office applications using VBA. I put all of these together using Office 2003 on a Window 7 computer.
My organization finally got around to moving over to using Windows 10 and Office 2016, and the changeover broke all of the scripts that open one application from the other.
Each script uses these two lines to start the other application:
Dim objExcel As Excel.Application
Set objExcel = CreateObject("Excel.Application")
If I run this snippet from Word started as a standard user, I get an error saying, "Run-time error '429':
ActiveX component can't create object" and debugging tells me the error is from the 'CreateObject' line.
If I run Word as an Administrator, though, Excel starts like I expect it to and I'm able to work with the application object.
I don't want to have to run the application or the automation scripts as an administrator. I'm guessing this is a configuration issue, but my google-fu is failing me.
How do I allow access to the Office applications automation object model from standard users in Windows 10?

Related

Launching Excel Spreadsheet Containing COM Object Instantiation in VBA - From NSIS "Finish" Page - Gives Class not registered Error For Admin User

I am experiencing a strange occurrence when installing for a Standard user versus Admin.
My installer requests "Highest" authentication level then proceeds to register COM dlls using a registry file import to HKCU (instead of using regasm.exe directly). The COM is for use in VBA in Excel. This allows me to install on a per-user basis.
After installation I have the "Run app" checkbox checked on the Finish page. The process is:
The user clicks "Finish" and NSIS launches a VB.net exe I wrote
The VB.net exe writes some additional registry entries to HKCU (that don't have anything to do with COM) then launches Microsoft Excel
Excel opens and attempts to instantiate the COM object in VBA.
Here is the strange difference:
For the "Standard" user this all works perfectly.
For the "Admin" user I get:
Run-time error '-2147221164 (80040154':
Class not registered
Curiously, if I then close Excel and double-click the desktop shortcut Excel opens and instantiates the object for the Admin user with no problem.
So, effectively, this error only occurs for the Admin user during the initial installation process (e.g. when it is NSIS that launches the VB.net exe which then launches Excel).
This problem occurs both on Windows 10 64-bit with Office 365 64-bit as well as Window 10 32-bit with Office 365 32-bit. So, the bitness of the applications has nothing to do with it.
It's almost like the registry isn't "refreshing" for the Admin user during the initial installation.
Any ideas as to what is going on and what the code is to fix it?
Matthew
I'm guessing you are running into a UAC security feature. When running elevated, COM will not read the entries in HKCU (because a non-elevated application could write there and wait for an elevated application to use a hijacked COM class registration).
That being said, what you are doing does not make sense. If you are using RequestExecutionLevel Highest then you should be writing to the ShCtx registry root after setting SetShellVarContext to Current or All depending on whether you are elevated or not in .onInit.
If you want to ignore my advise and continue using your existing design then define MUI_FINISHPAGE_RUN_FUNCTION and use ShellExecAsUser, StdUtils.ExecShellAsUser or the ugly Explorer hack (Exec '"$WinDir\Explorer.exe" "$InstDir\MyApp.exe"').

How to send Outlook items, using Excel VBA, when in Task Scheduler after upgrade to Office 2013?

I use MS Office 2013 and Windows 7 in a networked environment.
I have an auto-open Excel VBA program that sends files via Outlook and is scheduled via Task Scheduler.
This ran when I was on MS Office 2010, but my computer was wiped and reinstalled with MS 2013.
Some key points:
The Excel files all work when I run them directly and the emails get sent via Outlook.
Task Scheduler works when I use the setting "Run only when user is logged on" and emails get sent via Outlook.
Task Scheduler works with the other parts of the Excel VBA when it runs as "Run whether user is logged on or not," but does not successfully send Outlook files. I know this because I included a line to save a file in a particular directory and it did save it there. I also saw Excel in the Task Manager processes. So it runs, but does not send the Outlook email.
Things I have tried already:
Changed DCOM settings for Microsoft Excel and Outlook Message Attachment
Created "C:\Windows\System32\config\systemprofile\Desktop" and "C:\Windows\SysWOW64\config\systemprofile\Desktop" directories
Using the Outlook Object Model in a Task Scheduler or in the context of a Windows Service is not supported, so this could explain some of the unexpected behaviour. See: https://support.microsoft.com/en-ca/help/237913/the-outlook-object-model-is-unsuitable-to-run-in-a-windows-service

PowerShell scheduled task to run script with Excel Com Object

Here is some strange behavior, I've got a PowerShell script that converts an XLSX file into a CSV file. This script runs in the console without issue.
Trying to schedule the task/script results in a CSV file with no data (0 Bytes).
In my searching, I found this TechNet forum post that proved helpful.
Essentially the scheduled task containing the Powershell script that uses the Excel ComObject fails because You have to create a folder (or two on a 64bit-windows). Once this was done, the task when run manually works as expected. It also works when a trigger is set and the user is logged off.
Is this type of behavior concerning the Excel ComObject documented anywhere at all? I spent 3 hours trying to get this to work.
C:\Windows\System32\config\systemprofile\Desktop
(64Bit)
C:\Windows\SysWOW64\config\systemprofile\Desktop
AFAIK There are no official documentation from MS about this issue/limitation. It should be reported as a bug (contact Microsoft Support).
The requirement of a desktop folder (which SYSTEM doesn't have by default) shouldn't be necessary for excel to run and at least it should have created the folder if missing.
I don't believe Microsoft supports what you are attempting to do. According to this documentation, Microsoft states:
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.
The documentation appears to be for Office 2003, but I'm not sure if they have changed there stance since then as I haven't found other documentation stating support. As recently as 2009, this MVP reiterates that it isn't supported. The recommendations appear to be to use OpenXML SDK for non-interactive automation, or another third party library for working with the file format directly.

ExportAsFixedFormat with Excel fails

I try to convert Excel files to PDF via COM automation. The code runs as a service using the system user. Unfortunately, I get the error "0x800A03EC" in the ExportAsFixedFormat() function. It works when I run this in an interactive session.
I've heard the systemprofile needs a Desktop folder, so I added those.
I've heard this also might have to do with the system user not having a default printer, so I added values to the following keys:
HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Devices
HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts
But this only makes Excel hang instead of throwing an exception immediately.
I'm out of ideas and thankful for any help.
You have to select a default printer for this user. Try to import following code into your registry. Note: Replace these printers for your own (virtual) printers.
Windows Registry Editor Version 5.00
[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Devices]
"Send To OneNote 2010"="winspool,nul:"
"Microsoft XPS Document Writer"="winspool,Ne00:"
[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts]
"Send To OneNote 2010"="winspool,nul:,15,45"
"Microsoft XPS Document Writer"="winspool,Ne00:,15,45"
[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows]
"UserSelectedDefault"=dword:00000000
"Device"="Send To OneNote 2010,winspool,nul:"
Of course you still have to create your Desktop folder in
C:\Windows\SysWOW64\config\systemprofile
or in
C:\Windows\System32\config\systemprofile
depending on your setup.
After these steps you should be able to export Word, Powerpoint and Excel to PDF by using a regular, non-interactive service (e.g. Windows NT/SYSTEM user). You don't need any alterations in your Component Services
Wrong:
[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows]
"UserSelectedDefault"=dword:00000000
"Device"="Send To OneNote 2010,winspool,nul:"
Correct:
[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows]
"UserSelectedDefault"=dword:00000000
"Device"="Microsoft XPS Document Writer,winspool,Ne00:"
I struggled with this mightily and this post was so close. After trying a number of other things I knew this post was close and thought I'd try something.
For the record, the "Desktop" folder fix in systemprofile fixed this issue when we were running Windows Server 2008 R2 and Excel 2013 Automation. This only started being an issue for after we upgraded to Windows Server 2012 R2 and Excel 2016. To eliminate Excel as the culprit, I tried on a server with Windows Server 2012 R2 and Excel 2013 and experienced very similar issues.
All automation worked just fine under Network Service, but ideally, we wanted to run our site under ApplicationPoolIdentity.
First things first, the application pool running with ApplicationPoolIdentity needs to Load the User Profile.
Start Run -> inetmgr
expand Server -> Application Pools
right click on your App Pool -> Advanced Settings
under Process Model -> Load User Profile <-- should be set to true
So now I had to figure out who this identity was. Maybe there's a better way to do this, but since I added the user to IIS_IUSRS this is where I found the information.
Windows -> Edit local users and groups
Groups -> right click IIS_IUSRS -> Add to Group...
Add...
Locations... (choose local server), click OK
In the Enter the object names to select box type IIS APPPOOL\<app pool name>
(note the space and the triple P)
also, <app pool name> is the name of your Application Pool in inetmgr
Now you should see as a Member of IIS_IUSRS IIS APPPOOL\ (SID) where SID is your applicationpoolidentity security identifier in windows. This will be a very long alpha-numeric dashed string like "S-1-5-##-#########-#########-##########-#########-#########"
Unlike the answers above, this was the user I needed to edit in the registry.
So now following the above answers I had to add the following to the registry. Note: Adding the keys to S-1-5-18 did not solve the issue, I had to add them to the SID of the ApplicationPoolIdentity found above.
[HKU]\SID\Software\Microsoft\Windows NT\CurrentVersion\Devices
"Send To OneNote 2010"="winspool,nul:"
"Microsoft XPS Document Writer"="winspool,Ne00:"
[HKU]\SID\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts
"Send To OneNote 2010"="winspool,nul:,15,45"
"Microsoft XPS Document Writer"="winspool,Ne00:,15,45"
[HKU]\SID\Software\Microsoft\Windows NT\CurrentVersion\Windows
"UserSelectedDefault"=dword:00000000
"Device"="Microsoft XPS Document Writer,winspool,Ne00:"
Notice how I used the "Correct" response from eletre/Robert. Using the OneNote option for Device did not work for me.
Hopefully this saves someone the trouble of hunting this down some day.

Excel OLE - .NET COM AddIn behaves differently when Excel is embedded in an application

I have a .NET (C#) addin that uses a COM Shim dll to load itself into Excel. The addin works fine without any problem when Excel is run normally. The addin displays its own custom toolbar in Excel that is used to execute different commands.
When I embed Excel into another application (e.g. DSOFramer etc), the addin starts behaving strangely. It seems that if I disable a button on its toolbar then it does not get enabled again after setting the Visible property.
Also, I get a bunch of "Object reference not set" errors because the Application::Selection object is NULL which never happens when Excel is running normally. Sometimes I also get permission errors when Application::GetAddIns() method is called.
I am not sure what is happening here and I could not find an articles that explains the behavior of Excel COM Addins when Excel is embedded inside other application.
I have to admit I don't know much about dSOFramer, but I did run across the following items. I don't know if these help at all.
link text
link text
I contacted Microsoft Professional for this issue and found out that Microsoft now discourages embedding office applications. I was suggested to either stop embedding Excel into the application OR use only Excel 2007 that has a Ribbon UI. According to MS, the Ribbon UI does not have these issues.
The problem with the CommandBars is that the negotiation only happens during the OnConnection and no changes can be made afterwards.

Resources