![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| | 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? |
My System Specs![]() |
| | #2 (permalink) |
| | RE: Exchange 2007 Administration through 32-bit windows service. 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? |
My System Specs![]() |
| | #3 (permalink) |
| | Re: Exchange 2007 Administration through 32-bit windows service. 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 |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| RSAT Exchange tabs (Remote Server Administration Tools) | Vista account administration | |||
| Exchange Management Tool and Administration of group directors | Vista installation & setup | |||
| Stop the smtp service on an Exchange 2007 server? | PowerShell | |||
| Microsoft Readies IT Customers for Windows Vista, the 2007 Office System, Microsoft Exchange Server 2007 | Vista News | |||
| Microsoft Readies IT Customers for Windows Vista, the 2007 Office System, Microsoft Exchange Server 2007 | Vista News | |||