I have a console application that uses COM automation to manipulate .DOC and .DOCX files in Word 2010. This works in a scheduled task for a not logged in user account on two development machine (running 32 bit Windows Server 2003) but not on another machine (running 64 bit Windows Server 2003). It does run on that machine if run from the command line by the same user account when logged in (so I don’t think it’s a 32/64 bit issue).
The code hangs at the point it tried to open a document not when the Word application is created.
I have logged in as the user account and opened the file manually (so I don’t think it is popping up any dialog boxes).
I thought that it might be something to do with autocorrect and while looking at the proofing options noticed that the “automatically use corrections from the spelling checker” checkbox is greyed out.
I have used process monitor and could not find any file access failures for files which are on the dev machine but not on the other (Word seems to look for Normal.dot in a number of places but this file in not on the dev machine either).
I am aware that Word automation on a server is not recommended or supported by Microsoft and may be outside the terms of the license.
I am using automation as I need to manipulate files for older versions of Word.
This may be related to my other issue with automation from non logged in accounts: Why might COM automation from within a console application work on my development machine but not on another? However this case is different in that opening a file is hanging rather than creation of the application program failing.
What else should I try?
Related
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.
We have an application that can run as a Windows service (or as a user mode app). As part of it's processing, it launches a second executable that interacts with MAPI to read the contents of an MSG file. The executable is 32 bit. Office is 32 bit. So far, we've only tested using Outlook 2013.
This has worked fine for quite some time, but we've recently discovered a corner case where things do not work.
When we run as a Windows Service, and Outlook is not running in the user's session, then the application runs properly. However, if we launch Outlook, then MAPIInitialize fails with a return code of -7 (0xfffffffd).
I've tried calling with and without the MAPI_NT_SERVICE flag added (honestly, I can't figure out what that flag actually does), but it makes no difference.
So far in our testing, the Windows service account has been the same as the user logged into the Windows session that has Outlook installed - not sure if that might be important or not.
I can't for the life of me figure out how a process running under one session could interfere with a process running in another session.
I found this post a few minutes ago: https://social.msdn.microsoft.com/Forums/office/en-US/7a9cc40a-ffd6-4f83-9973-5410615b4df4/mapi-working-when-accessed-from-normal-application-but-not-from-the-service?forum=outlookdev
I'll give that a shot, but it seems super unlikely that this could be the issue (it's not like we do anything different with COM initialization, and certainly that wouldn't have anything to do with whether Outlook was running or not).
Can anyone point me in direction(s) to pursue this?
=============
More interesting information:
This appears to only happen with Outlook 2013. It definitely does not happen with Outlook 2010.
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 problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
I'm having trouble generating a PDF-file with PDFCreator from Excel macro (using VB.NET 3.5 and Interop).
Through Windows login as the domain user I can run the macro directly from Excel and everything works fine (a pdf file is printed and saved), but when published and run as the same user from server there is no printer found.
In the macro I know this can be solved by setting Application.ActivePrinter ("PDFCreator on Ne00:" in my case), which again works when I run directly from Excel but not from server. So what I wonder is how to make it possible to set ActivePrinter when running on server?
It worked with previous IIS version on the server (6.0). I have tried giving the domain user access permissions (e.g. in DCOMCNFG), the PDFCreator is set up correctly and accessible, don't really know how to approach this.
Using Office Interop from server-like scenarios (IIS/ASP.NET/Windows Service...) is NOT supported by MS - see http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757#kb2
Another point is that since windows vista there have been several security-related changed which prevent doing any "desktop-like" things (for example printing...) from a Windows Service...
Alternative to Interop:
To create PDF from Excel file there are several libraries out there which do not use Excel and work fine in server-scenarios - like Flexcel, Aspose.Cells, SpreadsheetGear...
It works even in IIS8 also.
Give Microsoft Excel Application sufficient Permission from DcomConfig (Eg-IIS_IUSRS,Network Services etc)
take care of impersonate user id and password provided In Web.xml. do not make it true if not necessary. it worked for me when i removed this.