Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Can't extend web application. We get "Microsoft.SharePoint.Administr

  Asked By: Bobbi    Date: Feb 03    Category: MOSS    Views: 3646

Our problems have veered far enough off track that I thought it
warranted a new thread.

We've been trying to get SSL going on our server farm. We have a
3-server farm. We have a NetScaler load balancer.

The process and problems thus far:

- we opened up central admin and extended our site 'oursite.com' to a
new IIS Site and port number
- this, alas, only created the new IIS site on the machine with
Central Admin. It didn't put the site on the other two FE servers
- so, we disconnected oursite.com from this IIS site and manually
created a new site in IIS on each of the MOSS servers using a new port
number
- we went back to central admin and this time attempted to extent the
oursite.com web application to the existing IIS site we just created.

Here's where we get stuck:

An object of the type
Microsoft.SharePoint.Administration.SPWebApplicationProvisioningJobDefinition
named "Provisioning 15bd1307-d1a7-4ecb-abc4-c71055d0807e" already
exists under the parent
Microsoft.SharePoint.Administration.SPWebService named "". Rename
your object or delete the existing object.

Google is returning a handful of hits with related questions, but very
few answers.

So, a handful of questions:

1) When extending a web application and telling MOSS to create the IIS
site for you, should it be doing it on ALL front end servers for you?

2) Any idea what the above error is referring to?

3) Are we doing anything obviously incorrect in our process of
extending a web application?

I assume the error is timer-job related. I fwe go to the timer job
status, I see three "application server administration service time
job's listed...one for each server...and all say 'succeeded'. So
that's not helping much.

If I look at the IIS installs on each server, the one with Central
admin IS populated with MOSS files, but the other two are not.

Share: 

 

16 Answers Found

 
Answer #1    Answered By: Zoe Cotton     Answered On: Feb 03

I hate to jump into this thread  late, especially since I am not
intimately familiar with the NetScaler load  balancer. But here goes
anyway.



If the Certificate is on the NetScaler load balancer  and it is
translating the traffic form it to sharepoint  as http then you shouldn't
need to do anything to the sharepoint server  at all. The SharePoint
server would never see an https request to react to. At this point its
up to the NetScaler load balancer to scan the html being returned and
change any embedded http: links for the sharepoint server to https:
before it encrypts the packet and sends it out. Since it is acting as
the SSL endpoint for the request SharePoint doesn't even need to know
its running SSL.



If the load balancer can't do that then you have to see if it has the
capability to do SSL tunneling. Ie, pass https: traffic destined for
the SharePoint box directly to the SharePoint box. That's where you get
into needing to extend  the existing web  application to a separate zone
or adding an https: AAM to the box.

 
Answer #2    Answered By: Alexander Scott     Answered On: Feb 03

Unfortunately, I'm a novice MOSS admin  ad best,
and really no very little about the Netscaler product and SSL in
general so some of this info is coming second hand from me.

What you state was our initial reaction as well...we assumed there's
no reason for the MOSS farm  to care about SSL as the netscaler is
handling it.

Apparently, we're using "out of the box SSL Termination" in Netscaler.
Netscaler support is telling our network folks that we do need to
reconfigure the MOSS farm to handle this setup. Of course, they don't
tell you what, specifically needs to be done.

We might have to call in some troops for this

 
Answer #3    Answered By: Benito Carey     Answered On: Feb 03

SharePoint WILL need to know about the SSL termination so it knows to
rewrite the outgoing URLS correctly with https links instead of http.

I was wrong, you do need to extend  the web  application. I
apologize for the confusion. I think you're on the right track  with the
Timer Job issue, I'm not sure why that change isn't being propagated.
Here is another great AAM resource,
blogs.msdn.com/.../what-every-sharepoin
t-administrator-needs-to-know-about-alternate-access-mappings-part-1.asp
x

 
Answer #4    Answered By: Ebony Perkins     Answered On: Feb 03

But if the load  balancer is actually doing the ssl  termination how would
SharePoint know that the incoming items are ssl to be able to rewrite
the links? Normally the choices are either to have the load balancer  do
an ssl tunnel and not terminate the ssl or have the load balancer doe
the link replacement. At least that's how I understood it. It's not
one of my areas of expertise.

 
Answer #5    Answered By: Anu K     Answered On: Feb 03

That's what the AAM does. It tells SharePoint if the incoming (called
"Internal" in the UI) is http://www.blah.com then any links on the pages
SharePoint returns to the user (the "Public" URL) should be written as
https://www.blah.com. It doesn't however encapsulate the packets in
SSL, the load  balancer does that on the way out.

At least that's how I understand it.

 
Answer #6    Answered By: Josie Barron     Answered On: Feb 03

I wasn't thinking about using the public URL to remap the outgoing
links. Most of what I have done with AAMs has dealt with setting up
alternate authentication. So I've normally done an Internal AAM for
HTTPS: to make sure that incoming requests that are https return https
and ones that are http return http. I hadn't thought  about using an
http addresss Public URL to map links on an incoming http to outgoing
https links.

 
Answer #7    Answered By: Tamika Cummings     Answered On: Feb 03

First, going back  to the extending web  application issue. When I do
that, and choose 'create new IIS site' should moss  create said new IIS
site on each and every server? That's not happening here, so we might
have a MOSS issue at that point. The timer  jobs think they finished
succesfully, but nothing is happening on the other two servers  IIS.

I think we're now at the point where this is really a Citrix support
issue. We need to figure out what exactly the NetScaler device does
and does not do. Our initial understanding was that Netscaler, itself,
is doing the URL rewriting. Ie, it gets the https request, rewrites it
to http, sends it to moss, moss returns http, netscaler changes it and
any other links to the url in the HTML to https, and sends it back to
the browser. Their literature hints at that but doesn't go into
detail.

 
Answer #8    Answered By: Linsey Bauer     Answered On: Feb 03

I seriously doubt the provisioning  issue is a netscaler problem. The
last time  I got this error  it was because the previous Web app creation
hung in the configDB. That was bad and took a rebuild. I talked to some
Microsoft folks, and tried 'remove SharePoint from IIS site' in Central
Admin. You could try that and see if it the extendedoursite.com exists.
Central Admin looks in the IIS Metabase where you are running it from.
You could have a metabase issue there, i.e. corrupt or
extendedoursite.com already exists, but your error seems to be in the
configDB.



1. I would try restarting the Windows SharePoint Services Web
Applicatoin service  (Central Admin, Services on Server) on all WFEs

2. Do you have the SSL certificate loaded on the WFE Server, or is
it on the netscaler

a. Specifically, are you terminating the SSL session on WFEs?

b. If you are terminating SSL on the netscalers, and forwarding
HTTP to the WFEs, then the default internal URL should be SSL, and a
custom AAM to HTTPS

3. If IIS does the SSL termination, you don't have to extend  and
map to use SSL and HTTP. Make sure IIS has 80 and 443 are enabled for
the Web app. load  the certificate. Verify your AAMs are correct. IF IIS
doesn't terminate, then you DO have to extend and map to have a second
HTTP listener.

 
Answer #9    Answered By: Ivy Salinas     Answered On: Feb 03

Answer inline below:

> 1. I would try restarting the Windows SharePoint Services Web
> Applicatoin service  (Central Admin, Services on Server) on all WFEs

Will do.

> 2. Do you have the SSL certificate loaded on the WFE Server, or is
> it on the netscaler

It will be on the netscaler and terminated there (we're using SSL
termination on Netscaler)

> a. Specifically, are you terminating the SSL session on WFEs?

No, on Netscaler.

> b. If you are terminating SSL on the netscalers, and forwarding
> HTTP to the WFEs, then the default internal URL should be SSL, and a
> custom AAM to HTTPS

So, on the MOSS farm, the default internal url should be HTTPS?

Why is that? Isn't netscaler communicating with the farm  as HTTP?

I can certainly set up the internal url to be HTTPS.

I'm still not entirely clear what the AAM should look like. Should it
show both internal and external urls as HTTPS?

Does anything on the farm still need to have an HTTP address if it's
all being sent through NetScaler?

 
Answer #10    Answered By: Kevin Davis     Answered On: Feb 03

> b. If you are terminating SSL on the netscalers, and forwarding
> HTTP to the WFEs, then the default internal URL should be SSL, and a
> custom AAM to HTTPS. So, on the MOSS farm, the default internal url
should be HTTPS?

[re] I would. That way, alerts always work.

Why is that? Isn't netscaler communicating with the farm  as HTTP?

[re] SharePoint Server 2007 isn't SSL-aware. It only cares about the
header. In your case, that is HTTPS, not HTTP. If you are using host
headers, you may need to add one for the HTTP URL. Otherwise, it
shouldn't matter.

I'm still not entirely clear what the AAM should look like. Should it
show both internal and external urls as HTTPS?

[re] imho, default internal URL should be HTTPS. You can create  another
AAM (doesn't matter which zone, but I would probably use Intranet) for
HTTP if you want. SharePoint Server 2007 sees those as two different
URLs. That's good.

Does anything on the farm still need to have an HTTP address if it's
all being sent through NetScaler?
[re] No. But, I usually add an HTTP AAM to access for testing SSL
problems. Also, we sometimes access a Web application  over HTTP
internally to offload the processing SSL creates.

 
Answer #11    Answered By: Meenakshi Khochar     Answered On: Feb 03

Citrix support emailed back  saying we need to look at this document to
configure off-box SSL termination:

http://support.microsoft.com/kb/917064

Of course, that's for Portal Server, not MOSS, so not sure how applicable it is.

 
Answer #12    Answered By: Latrice Henson     Answered On: Feb 03

I would have both AAMs.



The section in the Q article 'stsadm.exe -o addalternatedomain' is the
same as setting AAMs from Central Admin.



Should work either way. But, I would have both AAMs. Just stick one on
Custom and one on Public.



Terrible interface, btw. Go to 'Edit Public Zone URLs' to add the second
AAM. http:/<CA_Site>/_admin/EditOutboundUrls.aspx . I suspect you are
going to 'Add Internal URLS' or choosing the Web app hyperlink.

 
Answer #13    Answered By: Nidhi Tiwary     Answered On: Feb 03

Apologies for maybe being dense, but the AAM interface is still confusing me.

So, I have this now:

http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com | default | http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com

I want to add this (I think):

https://domain.com | internet | http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com

I click on EDIT PUBLIC URLs and get this:

default: http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com" target="_blank" rel="nofollow">http://domain.com
intranet:
internet: https://domain.com
custom:
extranet:

I hit save, and end  up with this:

https://domain.com | internet | https://domain.com

If I click on that AAM to 'EDIT INTERNAL URLS' and try to change the
https to http there, I get this error:

--------------------------------
Error
You must specify the default zone URL for all Web applications. To
delete the Alternate URL Collection, remove the public URLs in all
other zones, and then remove the default zone URL.
--------------------------------

I'm googling that error  now, but it seems rather vague.

 
Answer #14    Answered By: Beatrice Serrano     Answered On: Feb 03

I just did it on my server, and it left HTTP alone. I do not know why it
is changing them both to HTTPS. I get:



http://domain.com" target="_blank" rel="nofollow">http://domain.com | Default | http://domain.com" target="_blank" rel="nofollow">http://domain.com

https://domain.com | Internet | https://domain.com



Did you extend  and map to a zone? You don't want to if Citrix is
terminating. That is the only think I can think of? That's a swag, btw.

 
Answer #15    Answered By: Maya Lewis     Answered On: Feb 03

Oh, that *is* what I get. Is that correct? If so, I guess I'm set up.
I was assuming the external one had to be https and the internal one
had to be http.

 
Answer #16    Answered By: Paola Mcmahon     Answered On: Feb 03

2. should have read 'internal URL should be HTTPS, and a custom AAM to
HTTP'

Note that all alerts are sent using the default internal URL.