Exchange 2007 Administration through 32-bit windows service.

I've a 32-bit compiled windows service which carries out many Exchange
administration and monitoring tasks through VBScripts and C++ utilities using
CDOEXM. I just started making changes for Exchange 2007 using powershell
because I thought that is the correct path. Well, I ran in to a problem where
loading of Microsoft.Exchange.Management.PowerShell.Admin
snap-in fails with the error - "No Windows PowerShell Snap-ins are
available for version 1"
("http://blogs.msdn.com/mstehle/archive/2007/01/24/kb-preview-error-no-windows-powershell-snap-ins-when-loading-exchange-powershell-snap-in.aspx").

I'm wondering what are my options here if I can't recompile my service
program as 64-bit application. If I write .Net managed code utility (*.exe
from *.cs) 32-bit/64-bit(?) using Exchange assembly, will I be able to invoke
through win32
service?

I came across API Wow64DisableWow64FsRedirection() and wondering if 32-bit
cmd.exe has an option to invoke 64-bit Powershell.exe which in turn can load
Exchange assembly.

Note: I also have ADSI programs which runs fine on 64-bit Windows 2003 with
Exchange 2007. Any limitation on using ADSI in win32 app?

Looks like there is no way for a 32-bit cmd.exe to invoke 64-bit
powershell.exe. So I copied
%systemroot%\system32\windowspowershell\v1.0\powershell.exe to
%MyApplicationInstallPath%\bin folder and then invoked
%MyApplicationInstallPath%\bin\powershell.exe from my script and it worked.
It successfully loaded Exchange admin assembly. Other than maintenance
(service packs) issue, this should work. Has anyone tried this?

I think Wow64*Wow64FsRedirection() APIs are needed only if you happen to
invoke a system utility from your own 32-bit application.

"RD" wrote:

> I've a 32-bit compiled windows service which carries out many Exchange
> administration and monitoring tasks through VBScripts and C++ utilities using
> CDOEXM. I just started making changes for Exchange 2007 using powershell
> because I thought that is the correct path. Well, I ran in to a problem where
> loading of Microsoft.Exchange.Management.PowerShell.Admin
> snap-in fails with the error - "No Windows PowerShell Snap-ins are
> available for version 1"
> ("http://blogs.msdn.com/mstehle/archive/2007/01/24/kb-preview-error-no-windows-powershell-snap-ins-when-loading-exchange-powershell-snap-in.aspx").
>
> I'm wondering what are my options here if I can't recompile my service
> program as 64-bit application. If I write .Net managed code utility (*.exe
> from *.cs) 32-bit/64-bit(?) using Exchange assembly, will I be able to invoke
> through win32
> service?
>
> I came across API Wow64DisableWow64FsRedirection() and wondering if 32-bit
> cmd.exe has an option to invoke 64-bit Powershell.exe which in turn can load
> Exchange assembly.
>
> Note: I also have ADSI programs which runs fine on 64-bit Windows 2003 with
> Exchange 2007. Any limitation on using ADSI in win32 app?

On Aug 8, 4:54 pm, RD <R...@discussions.microsoft.com> wrote:
> Looks like there is no way for a 32-bit cmd.exe to invoke 64-bit
> powershell.exe. So I copied
> %systemroot%\system32\windowspowershell\v1.0\powershell.exe to
> %MyApplicationInstallPath%\bin folder and then invoked
> %MyApplicationInstallPath%\bin\powershell.exe from my script and it worked.
> It successfully loaded Exchange admin assembly. Other than maintenance
> (service packs) issue, this should work. Has anyone tried this?
>
> I think Wow64*Wow64FsRedirection() APIs are needed only if you happen to
> invoke a system utility from your own 32-bit application.
>
>
>
> "RD" wrote:
> > I've a 32-bit compiled windows service which carries out many Exchange
> > administration and monitoring tasks through VBScripts and C++ utilities using
> > CDOEXM. I just started making changes for Exchange 2007 using powershell
> > because I thought that is the correct path. Well, I ran in to a problem where
> > loading of Microsoft.Exchange.Management.PowerShell.Admin
> > snap-in fails with the error - "No Windows PowerShell Snap-ins are
> > available for version 1"
> > ("http://blogs.msdn.com/mstehle/archive/2007/01/24/kb-preview-error-no-...").
>
> > I'm wondering what are my options here if I can't recompile my service
> > program as 64-bit application. If I write .Net managed code utility (*.exe
> > from *.cs) 32-bit/64-bit(?) using Exchange assembly, will I be able to invoke
> > through win32
> > service?
>
> > I came across API Wow64DisableWow64FsRedirection() and wondering if 32-bit
> > cmd.exe has an option to invoke 64-bit Powershell.exe which in turn can load
> > Exchange assembly.
>
> > Note: I also have ADSI programs which runs fine on 64-bit Windows 2003 with
> > Exchange 2007. Any limitation on using ADSI in win32 app?- Hide quoted text -
>
> - Show quoted text -

Any reason why you copy the 32bit posh into your appdir? why not
invoke it directly from the system32\p.. path?

If you have a good reason for placing it under your appdir, perhaps
you could sidestep the servicepack/update issue by creating a symlink
(junction) under your bin to the v1.0 directory.

- Oisin