mdomod

21 Jan 2014 4:22 PM

Super!

itworkedinthelab

21 Jan 2014 6:17 PM

Thanks always interesting the truth is I noticed this switch somewhere on web but wasn't sure what it saves me exactly:) now I know:)

David

3 Feb 2014 5:09 PM

Is there any workaround if the properties that you need are the ones that aren't returned, or if you are using the Set-*virtualdirectory cmdlets?

Rhoderick Milne [MSFT]

11 Feb 2014 2:49 AM

Not that I've seen David - if you need a property that requires a trip to the metabase, then get a coffee....

David

11 Feb 2014 7:42 PM

LOL. Thanks Rhoderick! I'm actually querying hundreds of servers, so it'll be more like take a day off. I'm looking into querying IIS directly via the webadministration module and invoke-command, so I'll let you know if I come up with a solution. Cmdlet should do this already. :-)

Rhoderick Milne [MSFT]

13 Feb 2014 2:01 AM

My sense of humour can be a bit blunt sometimes -- :) I suppose you could do that for read operations, but the product group will not have tested that for write tasks, thus we will not support that for regular Exchange tasks. Out of curiosity, what are you looking for? Cheers, Rhoderick

Brandon Marcus

26 Nov 2014 10:16 PM

Thanks for the helpful article Rhoderick. Here's my scenario though, which is a little different. I'm running the Get commands locally and it takes forever to run. This is the second and third exchange server. The first exchange server is in a different site/datacenter and running commands locally is fast. Not sure how to speed up RPC calls to the IIS Metabase on the additional two exchange severs. Is this authentication related, even though the commands eventually successfully return the results....after minutes of waiting.

Hados

10 Dec 2014 2:10 PM

Hi Rhoderick,

I was trying to find this information everywhere, I thought maybe I was being firewalled between sites perhaps, and that it timed out from trying a secured connection, dropped back to port 80 remote powershell, and finally went through.... but that wasn't it. I then started thinking along the lines of MTU limitations and your article pointing out that it actually deviates from port 80 remote powershell and actually sends RPCs finally clarified it for me.

Now I am wondering this: I have come across Kerberos auth issues via VPN before that can be resolved by forcing those packets to use TCP which can be fragmented and aren't limited by MTU the same way as UDP is, all via a registry key. So I wonder if the same logic can be applied here, and these RPC packets be forced to use TCP. It might then speed up the transmission between sites, if the gateways are the bottlenecks? I haven't tried it yet, wondering if anyone has?

Rhoderick Milne [MSFT]

11 Dec 2014 11:53 PM

Hi Hados,

I have also seen the fun of truncated packets due to the VPN overhead, not so happy memories with that one!

RPC between boxes should be TCP, I'd netmon to prove it though.

I do need to revisit this as its popping up with 365 installs at the moment.
When I get time........

Cheers,
Rhoderick