I posted a few days ago about an 800A0046 permissions issue I was
seeing only on a specific server as a specific type of user in regards
to a CreateObject fuction. I saw an example of someone else's FSO
script that used a subroutine to call their createobjects so I thought
I would try it, and it worked! but I don't know why.

Here is the script that bombs with a permissions denied for
CreateObject on line 2 (only for local admins and domain users; for
domain admins it runs fine):

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
MsgBox "Hello World"
Set fso = nothing

Here is the script that runs fine for all users:

Dim fso
sub blabla
Set fso = CreateObject("Scripting.FileSystemObject")
end sub
MsgBox "Hello World"
Set fso = nothing

Any idea why the subroutine fixed the issue?

Thanks!

Re: Why did a subroutine fix my problem? by Tom

Tom
Mon May 14 10:43:45 CDT 2007

On May 14, 11:20 am, getke...@gmail.com wrote:
> I posted a few days ago about an 800A0046 permissions issue I was
> seeing only on a specific server as a specific type of user in regards
> to a CreateObject fuction. I saw an example of someone else's FSO
> script that used a subroutine to call their createobjects so I thought
> I would try it, and it worked! but I don't know why.
>
> Here is the script that bombs with a permissions denied for
> CreateObject on line 2 (only for local admins and domain users; for
> domain admins it runs fine):
>
> Dim fso
> Set fso = CreateObject("Scripting.FileSystemObject")
> MsgBox "Hello World"
> Set fso = nothing
>
> Here is the script that runs fine for all users:
>
> Dim fso
> sub blabla
> Set fso = CreateObject("Scripting.FileSystemObject")
> end sub
> MsgBox "Hello World"
> Set fso = nothing
>
> Any idea why the subroutine fixed the issue?
>
> Thanks!

It seemed to work because you never actually invoke the subroutine, so
no attempt is made to create the FSO.

If you try this, I fully expect your problem to return ...

Dim fso
blabla '; invokes the subroutine
MsgBox "Hello World"
Set fso = nothing
' Placing the subroutine outside of the 'main' code is merely
illustrative of how the
' process works. It isn't strictly required, but is a good practice.
sub blabla
Set fso = CreateObject("Scripting.FileSystemObject")
end sub

I would check your permissions on the problem server(s) - or the
status of any anti-virus software running. Only guessing.

Tom Lavedas


Re: Why did a subroutine fix my problem? by getkevin

getkevin
Mon May 14 11:08:33 CDT 2007

Hi Tom,

I think google mangled your post a little so I wasn't able to
reconstruct your example, however, I added some meat to the FSO
example:

Dim fso
sub blabla
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:\citrix.server") Then
CitrixServer = True
End If
end sub
MsgBox "Hello World"
Set fso = nothing

This worked as well. As soon as I rem out the sub blabla, I'm back
with the permissions error. Again, if you are a domain admin it
executes fine. Local admins and domain users cannot. I don't know
where I'd begin to troubleshoot file permissions if it happens to a
local admin.


On May 14, 11:43 am, Tom Lavedas <tglba...@cox.net> wrote:
> It seemed to work because you never actually invoke the subroutine, so
> no attempt is made to create the FSO.
>
> If you try this, I fully expect your problem to return ...
>
> Dim fso


> blabla '; invokes the subroutine
> MsgBox "Hello World"
> Set fso = nothing
> ' Placing the subroutine outside of the 'main' code is merely
> illustrative of how the
> ' process works. It isn't strictly required, but is a good practice.
> sub blabla
> Set fso = CreateObject("Scripting.FileSystemObject")
> end sub
>
> I would check your permissions on the problem server(s) - or the
> status of any anti-virus software running. Only guessing.
>
> Tom Lavedas



Re: Why did a subroutine fix my problem? by Tom

Tom
Mon May 14 15:40:54 CDT 2007

On May 14, 12:08 pm, getke...@gmail.com wrote:
> Hi Tom,
>
> I think google mangled your post a little so I wasn't able to
> reconstruct your example, however, I added some meat to the FSO
> example:
>
> Dim fso
> sub blabla
> Set objFSO = CreateObject("Scripting.FileSystemObject")
> If objFSO.FileExists("C:\citrix.server") Then
> CitrixServer = True
> End If
> end sub
> MsgBox "Hello World"
> Set fso = nothing
>
> This worked as well. As soon as I rem out the sub blabla, I'm back
> with the permissions error. Again, if you are a domain admin it
> executes fine. Local admins and domain users cannot. I don't know
> where I'd begin to troubleshoot file permissions if it happens to a
> local admin.
>
> On May 14, 11:43 am, Tom Lavedas <tglba...@cox.net> wrote:
>
> > It seemed to work because you never actually invoke the subroutine, so
> > no attempt is made to create the FSO.
>
> > If you try this, I fully expect your problem to return ...
>
> > Dim fso
> > blabla '; invokes the subroutine
> > MsgBox "Hello World"
> > Set fso = nothing
> > ' Placing the subroutine outside of the 'main' code is merely
> > illustrative of how the
> > ' process works. It isn't strictly required, but is a good practice.
> > sub blabla
> > Set fso = CreateObject("Scripting.FileSystemObject")
> > end sub
>
> > I would check your permissions on the problem server(s) - or the
> > status of any anti-virus software running. Only guessing.
>
> > Tom Lavedas

Your latest post still does NOT invoke the subroutine. A comment line
wrapped in my original response thereby causing the error, but I would
think your problem still remains.

Try this ...

Dim fso, CitrixServer
blabla '; invokes the subroutine
MsgBox "Hello World " & CStr(CitrixServer)
Set fso = nothing

sub blabla
Set fso = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:\citrix.server") Then
CitrixServer = True
end sub

I believe it will throw the original error.

Tom Lavedas


Re: Why did a subroutine fix my problem? by getkevin

getkevin
Mon May 14 17:41:01 CDT 2007

Well, no luck with your script. There is no 'end if' for the 'if
objFSO..." line in your example so I added it to get past the first
error, but it now complains about object required 'objFSO' for line 9
(if objFSO....).

Kevin

On May 14, 4:40 pm, Tom Lavedas <tglba...@cox.net> wrote:
> Try this ...
>
> Dim fso, CitrixServer
> blabla '; invokes the subroutine
> MsgBox "Hello World " & CStr(CitrixServer)
> Set fso = nothing
>
> sub blabla
> Set fso = CreateObject("Scripting.FileSystemObject")
> If objFSO.FileExists("C:\citrix.server") Then
> CitrixServer = True
> end sub
>
> I believe it will throw the original error.


Re: Why did a subroutine fix my problem? by Michael

Michael
Mon May 14 21:16:08 CDT 2007

On 14 May 2007 15:41:01 -0700, getkevin@... wrote in microsoft.public.scripting.vbscript:

>Well, no luck with your script. There is no 'end if' for the 'if
>objFSO..." line in your example so I added it to get past the first
>error, but it now complains about object required 'objFSO' for line 9
>(if objFSO....).

I suspect like Tom that there are underlying permissions issues. Tom's
code may have been mangled in that some one-liners have been wrapped -
a proper news reader wouldn't have; he also seems to be inconsistent
between "fso" and "objFSO" - easily enough corrected, see below.

>On May 14, 4:40 pm, Tom Lavedas <tglba...@cox.net> wrote:
>> Try this ...
>>
>> Dim fso, CitrixServer
>> blabla '; invokes the subroutine
>> MsgBox "Hello World " & CStr(CitrixServer)
>> Set fso = nothing
>>
>> sub blabla
>> Set fso = CreateObject("Scripting.FileSystemObject")
>> If objFSO.FileExists("C:\citrix.server") Then
>> CitrixServer = True
>> end sub
>>
>> I believe it will throw the original error.

01 Dim objFSO, CitrixServer
02 blabla(CitrixServer) '; invokes the subroutine
03 MsgBox "Hello World " & CStr(CitrixServer)
04 WScript.Quit
05
06 Sub blabla(blnBool)
07 Set objFSO = CreateObject("Scripting.FileSystemObject")
08 If objFSO.FileExists("C:\citrix.server") Then blnBool = True
09 End Sub

Line 08 could also be re-written as
08 blnBool = objFSO.FileExists("C:\citrix.server")

or lines 07 and 08 could be combined into one single line:
07 blnBool = CreateObject("Scripting.FileSystemObject").FileExists("C:\citrix.server")

In fact, the whole program can be written in one line (tested):
01 MsgBox "Hello World " & CreateObject("Scripting.FileSystemObject").FileExists("C:\citrix.server")

--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"

Re: Why did a subroutine fix my problem? by Tom

Tom
Tue May 15 06:35:12 CDT 2007

Yes, cut and paste and haste errors. Thanks for taking the time to do
it right.

Line wrapping can occur on either end - in my case, at google.groups.

BTW, the one-liner gets away from the original intent of proving that
putting the CreateObject for the FSO in a subroutine would not solve
the underlying error.

Tom Lavedas

On May 14, 10:16 pm, Michael Bednarek <ROT13...@gtz.pbz.nh> wrote:
> On 14 May 2007 15:41:01 -0700, getkevin@... wrote in microsoft.public.scripting.vbscript:
>
{snip}
> I suspect like Tom that there are underlying permissions issues. Tom's
> code may have been mangled in that some one-liners have been wrapped -
> a proper news reader wouldn't have; he also seems to be inconsistent
> between "fso" and "objFSO" - easily enough corrected, see below.
>
> >On May 14, 4:40 pm, Tom Lavedas <tglba...@cox.net> wrote:
> >> Try this ...
>
{snip}
> In fact, the whole program can be written in one line (tested):
> 01 MsgBox "Hello World " & CreateObject("Scripting.FileSystemObject").FileExists("C:\citrix.server")
>
> --
> Michael Bednarek http://mbednarek.com/ "POST NO BILLS"



Re: Why did a subroutine fix my problem? by getkevin

getkevin
Tue May 15 08:05:12 CDT 2007

Well, you are both right. I tried the updated script Michael posted
and indeed the same permissions error on CreateObject. Now
considering that something as simple as this:

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")
set fso = nothing

generates the error, but not for Domain Admins, what permissions would
you look at? The script hasn't even attempted to access something in
the file system so its not something like folder permissions. I have
compared the DCOM permissions from one Citrix server to another and
they look the same. This is bizarre.

Anyway, thanks for taking the time, I really do appreciate the help.
Kevin


Re: Why did a subroutine fix my problem? by Mole

Mole
Tue May 15 19:11:52 CDT 2007

have you yet even grasped the fact that your subroutine code was "working"
because you never CALLED the subroutine?!?!

if you have:

Sub mysub
msgbox "hello"
end sub

and run that code, guess what? you get NO message box. you have to CALL the
sub to run the code inside it.
so if you have a createobject INSIDE a sub, it never happens unless you call
the sub. do you get this?



<getkevin@gmail.com> wrote in message
news:1179234312.041792.258970@n59g2000hsh.googlegroups.com...
> Well, you are both right. I tried the updated script Michael posted
> and indeed the same permissions error on CreateObject. Now
> considering that something as simple as this:
>
> Dim fso
> Set fso = CreateObject("Scripting.FileSystemObject")
> set fso = nothing
>
> generates the error, but not for Domain Admins, what permissions would
> you look at? The script hasn't even attempted to access something in
> the file system so its not something like folder permissions. I have
> compared the DCOM permissions from one Citrix server to another and
> they look the same. This is bizarre.
>
> Anyway, thanks for taking the time, I really do appreciate the help.
> Kevin
>


Re: Why did a subroutine fix my problem? by Mole

Mole
Tue May 15 19:16:57 CDT 2007

have you yet even grasped the fact that your subroutine code was "working"
because you never CALLED the subroutine?!?!

if you have:

Sub mysub
msgbox "hello"
end sub

and run that code, guess what? you get NO message box. you have to CALL the
sub to run the code inside it.
so if you have a createobject INSIDE a sub, it never happens unless you call
the sub. do you get this?



<getkevin@gmail.com> wrote in message
news:1179234312.041792.258970@n59g2000hsh.googlegroups.com...
> Well, you are both right. I tried the updated script Michael posted
> and indeed the same permissions error on CreateObject. Now
> considering that something as simple as this:
>
> Dim fso
> Set fso = CreateObject("Scripting.FileSystemObject")
> set fso = nothing
>
> generates the error, but not for Domain Admins, what permissions would
> you look at? The script hasn't even attempted to access something in
> the file system so its not something like folder permissions. I have
> compared the DCOM permissions from one Citrix server to another and
> they look the same. This is bizarre.
>
> Anyway, thanks for taking the time, I really do appreciate the help.
> Kevin
>


Re: Why did a subroutine fix my problem? by getkevin

getkevin
Tue May 15 20:12:13 CDT 2007

Relax big fella, I get it. The example I posted above is back to the
original problem. The subroutine was an error on my part; now I am
back to trying to discern how a domain admin permissions will allow
the CreateObject to execute while a local admin's permission does
not. Do you get this?


On May 15, 8:16 pm, "Mole Man" <m...@m.m> wrote:
> have you yet even grasped the fact that your subroutine code was "working"
> because you never CALLED the subroutine?!?!
>
> if you have:
>
> Sub mysub
> msgbox "hello"
> end sub
>
> and run that code, guess what? you get NO message box. you have to CALL the
> sub to run the code inside it.
> so if you have a createobject INSIDE a sub, it never happens unless you call
> the sub. do you get this?