From: It's me again on
SBS 2008, being the odd duck that it is, moves certain virtual directories
from the Default Web Site to the SBS Web Applications site during
installation. Among the vdirs moved are the RPC and RPCwithCert vdirs that
are critical to Outlook Anywhere. These vdirs are associated with the RPC
HTTP proxy feature. Now, if the RPC HTTP proxy feature is removed and then
added again in SBS 2008 using Windows Server Manager (which the last time I
looked was part of SBS 2008), the RPC and RPCwithCert vdirs are put in the
Default Web Site and Outlook Anywhere in a one cert installation is broken. I
have examined the script in the CAS role repair of Exchange Server (SBS
version) and do not see how the RPC and RPCwithCert vdirs are being moved.
Absent a cookbook procedure it would be nice if the RPC and RPCwithCert apps
were fully documented which would at least provide a way to recreate them in
the proper IIS 7 site. Somebody tell me there is an easy way to fix my broken
SBS 2008.
From: Russ SBITS.Biz [SBS-MVP] on
I'm unsure on what You've done.
You've Uninstalled RPC HTTP For a reason?
Was it not working or did you manually move a web directory or something?
and re installed it (How did you reinstall it?)

And you say one CERT Installation is Broken?
(More Details please.)

Errors in Logs etc.
Symptoms

Have you run the Configure network and network fix wizard?
or Run the Best Practices Analyzer and see what you can see.

Not to sound harsh but if you want the easiest way to fix this,
is to call someone and have them do it.

Be it Microsoft or your SBS Specialist guy.

Russ

--
Russell Grover - SBITS.Biz [SBS-MVP]
MCP, MCPS, MCNPS, SBSC
Microsoft Certified Small Business Specialist
SBS2003 SBS2008 Support - www.SBITS.Biz
Question or Second Opinion - www.PersonalITConsultant.com
Free Trial Microsoft Online Services - www.Microsoft-Online-Services.com


"It's me again" <Itsmeagain(a)discussions.microsoft.com> wrote in message
news:924AFA22-B832-4898-8B33-FC1AB848DAC1(a)microsoft.com...
> SBS 2008, being the odd duck that it is, moves certain virtual directories
> from the Default Web Site to the SBS Web Applications site during
> installation. Among the vdirs moved are the RPC and RPCwithCert vdirs that
> are critical to Outlook Anywhere. These vdirs are associated with the RPC
> HTTP proxy feature. Now, if the RPC HTTP proxy feature is removed and then
> added again in SBS 2008 using Windows Server Manager (which the last time
> I
> looked was part of SBS 2008), the RPC and RPCwithCert vdirs are put in the
> Default Web Site and Outlook Anywhere in a one cert installation is
> broken. I
> have examined the script in the CAS role repair of Exchange Server (SBS
> version) and do not see how the RPC and RPCwithCert vdirs are being moved.
> Absent a cookbook procedure it would be nice if the RPC and RPCwithCert
> apps
> were fully documented which would at least provide a way to recreate them
> in
> the proper IIS 7 site. Somebody tell me there is an easy way to fix my
> broken
> SBS 2008.

From: Cliff Galiher - MVP on
Since SBS 2008 is "built" on Windows Server 2008, it has the windows server
tools, including ADUC, ADSI, and the server manager snap-in.

That doesn't mean you should *use* these tools. If there isn't a wizard to
do something, that means one of two things:

1) It should not be done in SBS because of licensing or technology
restrictions.
2) It should only be done if there is a business need and a *very*
experienced Windows professional familiar with SBS is making those changes.

In this case, you used a tool that was not SBS aware to try and install
something and now things are very shuffled.

Depending on the extent of the damage, you have several options:

1) Restore a backup. Yes, this will re-introduce the problem you were
trying to fix, but chances are we can walk you through that and resolve the
issue more easily than the state you are in now.

2) Try the SBS wizards. In particular the FNCW and CTIW could be useful. I
doubt the IAMW wizard will do much in this instance, but it can't hurt
either. These wizards are interlaced, so the "I doubt" is literal; they've
surprised me by rebuilding stuff internally that I didn't expect them to
more than once.

3) Rebuild the exchange roles. There is a technet article on this. It is
very risky, very difficult, and step #1 would be MUCH more preferencial at
this point, but if you have somehow gotten yourself past the point of
return, it is an option. It is *SO* far out of the realm of a good option
though that I won't post the link until we've exhausted all other options.
Sorry, I just feel that strongly about it.

Hope that helps,

-Cliff


"It's me again" <Itsmeagain(a)discussions.microsoft.com> wrote in message
news:924AFA22-B832-4898-8B33-FC1AB848DAC1(a)microsoft.com...
> SBS 2008, being the odd duck that it is, moves certain virtual directories
> from the Default Web Site to the SBS Web Applications site during
> installation. Among the vdirs moved are the RPC and RPCwithCert vdirs that
> are critical to Outlook Anywhere. These vdirs are associated with the RPC
> HTTP proxy feature. Now, if the RPC HTTP proxy feature is removed and then
> added again in SBS 2008 using Windows Server Manager (which the last time
> I
> looked was part of SBS 2008), the RPC and RPCwithCert vdirs are put in the
> Default Web Site and Outlook Anywhere in a one cert installation is
> broken. I
> have examined the script in the CAS role repair of Exchange Server (SBS
> version) and do not see how the RPC and RPCwithCert vdirs are being moved.
> Absent a cookbook procedure it would be nice if the RPC and RPCwithCert
> apps
> were fully documented which would at least provide a way to recreate them
> in
> the proper IIS 7 site. Somebody tell me there is an easy way to fix my
> broken
> SBS 2008.

From: John on
I dont know why you guys are badgering Rob - but there should be a simple solution to properly register the RPC directory in IIS - what is it??

I have a kind of mirrored problem of this issue - my RPC directory exists in the proper SBS Web Applications vdir(never changed or removed it), but several Exchange Power Shell tests show that RPC is broken, and the tests think the directory is missing from the "Default Website" vdir - DUH! of course its missing - cause its in SBS Web Applications - not many issues from this - somehow remote Outlooks still work fine - but TS Gateway features are broke.

My gut feeling is to NOT run the wizards as they failed to setup the ssl cert with SANs properly configured with autodiscover in the first place. I feel deciphering that nasty guide that Rob posted that is loaded with Power Shell commands may be the only real solution. Working with SBS since Backoffice 4.0, I think I know my way around the block, and I have done my due diligence to research this - if I call MS support (which has crossed my mind) and they cant fix this in 15 minutes - where am I left?? - Means they tried the wizard and it didnt work. My last call to the Exchange department took 2 months to solve a problem, and the resolution was never known, except that its working again. Surely I respect these techs as being quite proficient, my hats are off to you guys, but sometimes it feels like you are thumping your MCSE bible at me.

Point being - MS should definitely better document RPC and how its tied to IIS - something tells me part of that script Rob linked to has the 3-4 lines that fix this hidden in there somewhere.

---
frmsrcurl: http://msgroups.net/microsoft.public.windows.server.sbs/Re-installation-of-RPC-HTTP-proxy-feature-leads-to-big-probl
From: Ace Fekay [MVP-DS, MCT] on
> I dont know why you guys are badgering Rob - but there should be a simple
> solution to properly register the RPC directory in IIS - what is it??
>
> I have a kind of mirrored problem of this issue - my RPC directory exists in
> the proper SBS Web Applications vdir(never changed or removed it), but
> several Exchange Power Shell tests show that RPC is broken, and the tests
> think the directory is missing from the "Default Website" vdir - DUH! of
> course its missing - cause its in SBS Web Applications - not many issues from
> this - somehow remote Outlooks still work fine - but TS Gateway features are
> broke.
>
> My gut feeling is to NOT run the wizards as they failed to setup the ssl cert
> with SANs properly configured with autodiscover in the first place. I feel
> deciphering that nasty guide that Rob posted that is loaded with Power Shell
> commands may be the only real solution. Working with SBS since Backoffice
> 4.0, I think I know my way around the block, and I have done my due diligence
> to research this - if I call MS support (which has crossed my mind) and they
> cant fix this in 15 minutes - where am I left?? - Means they tried the wizard
> and it didnt work. My last call to the Exchange department took 2 months to
> solve a problem, and the resolution was never known, except that its working
> again. Surely I respect these techs as being quite proficient, my hats are
> off to you guys, but sometimes it feels like you are thumping your MCSE bible
> at me.
>
> Point being - MS should definitely better document RPC and how its tied to
> IIS - something tells me part of that script Rob linked to has the 3-4 lines
> that fix this hidden in there somewhere.
>
> ---
> frmsrcurl:
> http://msgroups.net/microsoft.public.windows.server.sbs/Re-installation-of-RPC-HTTP-proxy-feature-leads-to-big-probl

John,

In Rob's case, I think the operative word is "re-register" or
"re-install" RPC, which falls under the Exchange 2007 CAS role.

I myself, have been curious from the beginning of this thread, as to
why Rob had to removed RPC to begin with. Was there a problem that
prompted hinm? I don't know. I was trying to read through the rhetoric,
but I cannot ascertain or find any stated reason, even after he was
asked as to why.

Nontheless, the deed has been done, for whatever reason, and he's
trying to repair it. He mentioned the CAS repair link, but he didn't
mention if he followed it, and if so, if it worked. I am also curious
if he followed the KB, if it worked or not.

And btw John, the link you provided at the bottom of your post, is
actually a link to this thread. I don't know if you are aware of that
or not, or if it was automatically placed by the web-based newsgroup
access method or site that you used to access this group.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit
among responding engineers, and to help others benefit from your
resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE
& MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance,
please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.