Has anybody tried to execute Visual Basic from an Automate task to start up a Word 2007 instance?
The reason I'm asking is that I'm trying to port a task which work fine in 32-bit Windows 2003 to 64 bit Windows 2008.
If I execute in Task Builder it runs fine, but using Automate scheduling the task just hangs at the point where the Word instance is started, The Word instance seems to start fine, but then is just stuck with Word just accumulating memory.

Just wondering if there is any problem calling VB on 64-bit Windows.

Category Survey

Jacobus,
it works for me


Sub Main
Set wd =CreateObject ("Word.Application")
wd.Visible = True
wd.Documents.Open("\\HP-1490\SharedDocs\Fichiers\Divers\Convives.doc")

MsgBox"Excel window is present"
End Sub

Could you post your vb if it does not for you ?

I attach an export of the sample file

Category Survey AutoMate 7 version: Windows version:

-------------------------
Jean Delfosse - Automate Beta Tester
Win7 Pro 64 bits -Win XP Pro SP3 32 bits - AM8, AM7, BPA10, BPA9, BPA8, BPA7, AM6 Enterprise, AM4


Edited: 02/23/2010 at 10:04 PM by JeanDelfosse

Jean,
Thanks. I think your script has helped me to track down the problem further, since you script and mine shows exactly the same problems.

I've got a very simple script that works fine in XP and Wondows 2003 server - both 32 bit. It just will not work under Windows 2008 server, 64 bit. My script only start Word and terminates it immediately again, using .visible = False , so that it does not require any screen output.

Sub Main
'
' This program attempts to get rid of Word Recovery files. It just starts and stop Word
'
Dim WrdApp As Word.Application
On Error GoTo Goterror
' Create a new instance of WORD
Set WrdApp = New Word.Application ----> hangs here & similar line in your script
' Make it invisible (background run)
WrdApp.Visible = False
With WrdApp
.Application.Quit
End With
Set WrdApp = Nothing
Exit Sub
Goterror:
WRD_EFOUND = 1
WRD_ERR = Err.Source
WRD_ENUM = Err.Number
WRD_EDESC = Err.Description
With WrdApp
.Documents.Close(0)
.Application.Quit
End With
Set WrdApp = Nothing
Exit Sub
End Sub



What I have now found out with both scripts, is that they will work if I set the task logon tab to "When workstation is logged on: Logged on user".
If I set it to "Background user" or "Specified User", then it just hang on the step where Word is started (both your script and mine).

So I'll have to work through the parameters and registry to try and find out what is causing the problem. I've already noticed that the SAS setting on the Logon tab (System Options) does not work.

My other jobs are all set to run as "Background User" and they all run fine, just the job(s) that tries to run Word doesn't work.

Oh well, back to digging. :-)

Category Survey

Jacobus,
I don't have today more time to test, but I had an idea :
It might be worthwhile trying to open Word via a run action, in a minimized mode, then to get the link in vb thru a GetObject.

Maybe you could test that ? Who knows ?

Category Survey AutoMate 7 version: Windows version:

-------------------------
Jean Delfosse - Automate Beta Tester
Win7 Pro 64 bits -Win XP Pro SP3 32 bits - AM8, AM7, BPA10, BPA9, BPA8, BPA7, AM6 Enterprise, AM4

Ahh Jean,
There's an English saying which goes "Great minds think alike". Of course there's another one which goes "Fools never differ".

I've already tried it. Same result. If using "Logged on user", it works, not so if set to background user.

I'm now leaning to the LOGON system setting "Enable software SAS. I cannot get it set, while according to the description it must be set for Windows 2008 Server & Windows 7.

Category Survey

Hi Jacobus,

When you enable SAS does it appear to disable shortly after? It looks like a security policy is being applied that prevents SAS from enabling.

Category Survey AutoMate 7 version: Windows version:

-------------------------

Leonard Amabile | Director, Cross Platform Support
AutoMate | InterMapper | Skybot | Divisions of HelpSystems
T: +1.213.738.1700 | F: +1.213.738.7665

I've got it set in the end, but it still did not solve the problem.
I'll post a small script tomorrow that can be tried out with Windows 2008.

Category Survey

We have determined that disabling the UAC prompt in Windows prevents Automate from sending a CTRL ALT DEL to logon or unlock the workstation. In order for the logon/unlock process to function correctly, UAC needs to be enabled.

You may do so from either of the following:

secpol.msc:
Local Policies > Security Options > User Account Control: Detect application installations and prompt for elevation
Enabled (default) / Disabled

registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA
1 (default) / 0

Setting any one of the above settings to its default and restarting the workstation will correct the issue.

Category Survey AutoMate 7 version: Windows version:

-------------------------

Leonard Amabile | Director, Cross Platform Support
AutoMate | InterMapper | Skybot | Divisions of HelpSystems
T: +1.213.738.1700 | F: +1.213.738.7665

Leonard,
I've sent via email a copy of the script and a Word document with other information, e.g. registry settings. This the same problem as was reported in the thread " Logon specified user is not logging on to console" and that was the subject heading used for the email.

Category Survey

Hi Jacobus,

I understand we have a remote session scheduled on Thursday. We will address all of your outstanding issues then.

Category Survey AutoMate 7 version: Windows version:

-------------------------

Leonard Amabile | Director, Cross Platform Support
AutoMate | InterMapper | Skybot | Divisions of HelpSystems
T: +1.213.738.1700 | F: +1.213.738.7665

I finally found a solution for this problem, and it is the weirdest one I've come across in a long time.

The fix is to create folder c:\windows\syswow64\config\systemprofile\desktop for 64-bit Windows 2008 server.

I assume that for 32-bit Windows 2008 the file will be C:\Windows\System32\config\systemprofile\Desktop

This folder existed under Windows 2003, but dissappeared in Windows 2008. I think this may have been deliberate, since Microsoft doesn't really want you to have unattended Office operations.

The same folder may also need to be created if you are having problems with Excel.

Category Survey

Jacobus,
looks like you deserve a medal for finding this tricky one ! Congratulations.

Category Survey AutoMate 7 version: Windows version:

-------------------------
Jean Delfosse - Automate Beta Tester
Win7 Pro 64 bits -Win XP Pro SP3 32 bits - AM8, AM7, BPA10, BPA9, BPA8, BPA7, AM6 Enterprise, AM4

Hi Jacobus,

I had the same exact issue trying to run basic script to open excel and run macro.

I created the 2 Desktop folders as you suggested and it worked.

C:\windows\syswow64\config\systemprofile\Desktop
C:\Windows\System32\config\systemprofile\Desktop

I don't why that fixed it...but it works now.

How in the world did you find this?

Thanks,
Nick

Category Survey