Posted By tvogel on 07/23/2008 5:53 PM
Yes, I am using a credential object that I create.

So, using Powershell and the Exchange management cmdlets, there is no way that I can access multiple organizations (servers in compeltely different AD forests) within a script?

I think the answer here is that your *current* PowerShell session that you have running when you call get-exchangeserver needs to be running with the credentials of a user that has access to the remote systems.

get-exchangeserver doesn't support a credential object, but it is "picking up" your currently logged in credentials.  It is those credentials that don't have access to the remote Exchange server.

That's what I'm gathering anyways...

So basically, if you can log into your system with those same credentials that you are using to create your credential object, then your PowerShell session will automatically use those when get-exchangeserver connects to that remote system.

Make sense?

Posted By tvogel on 07/24/2008 6:36 AM
Marco -

I understand what you are saying, but no it does NOT make sense. Basically you are saying we can not use Powershell to administer multiple customers (different organizations) from a central machine because for some reason the EXCHANGE cmdlets in Powershell do not work like other cmdlets.

We can not constantly be logging on and off a machine so that the tool can use our "logged in" credentials - plus, from a security standpoint, that doesn't make sense either....our engineers accounts do not have permissions to do things DIRECTLY in our customer's environments....we need the ability to authenticate with alternate credentials to do administrative tasks.

Does it use the credentials of the user actually logged in the machine or the credentials used to start powershell.

Not all cmdlets are created equal...  I don't know which creds will be used.  I'll try that later, but it could be a day or so.  I can't remember the .NET class I can use to get this quickly...

Well, if I had time, I'd look into how this could be extended with credentials, likely using a script and/or script cmdlet, but I just don't have the time.  Sorry...

Good feedback for Microsoft if you have an inside Exchange contact...

Posted By Karl on 07/24/2008 7:22 PM
I am not sure about the exchange cmdlets, but if this is true. you can still work around it..

you could start another powershell.exe instance in the context of a different user, and run scriptblocks to the different exchange instancesw through that, using automatic, or explicit (*-clixml) cmdlets to serialize and deserialize the objects returned.

-Karl

And you would do this so you can pass your object from one PowerShell session to another?  You would lose access to the methods of your object, but the whole point of get- is to be able to read-only anyways.

Interesting approach...

here's the deal, no it cannot be done now :-)

Point is, that in some cmdlets, the EMS doesn't accept credentials, and
therefor, doesn't allow you to define correct credentials to pass along
with the cmdlet.

Example
It's possible to retrieve a list of mailboxes in forest B when running
the shell in forest A
By using:
$credential=get-credential (specify user + password in other forest)
Get-Mailbox -DomainController DC.forestB.com -Credential $credential

Works without a problem. But when using Get-MailboxStatistics, EMS
doesn't accept credentials.

Solution: start shell and run it as a user in forest