What you're looking for is the host named site collection, which enables you to assign a unique DNS name to site collections. Or alternatively create an AAM for existing Site collection to achieve it. For example, you can address them as http://hr.mycompany.com or http://sales.mycompany.com.
The sample PowerShell code creates a new web application listing ...
There are some online-tipps which recommend the use of the IIS Rewrite module. I do not prefer this way.
My preferred way is done with SharePoint AAMs and IIS-Bindings:
Alternate Access Mappings: Configure your HTTPS URL in Default-Zone. Add an additional "Internal URL" and map it to the "Default" Zone. Should look like this:
Add both the HTTP and the ...
You can disable the http binding in your IIS. Open the site and have a look on the right side under "Actions" you will find "Bindings". Allow only the 443 binding with a valid certificate for your site and remove the 80 port binding ;) If you do this then users will not be able to reach anything with http anymore for this site.
You can use the Rewrite ...
As a Best Practice, you never want to reference your SharePoint installation using the machine name so you are on the right track.
Add "portal.mysp.test" to your DNS
Add "portal.mysp.test" as the name of your Default or Intranet zone in SharePoint
You might need to also add "portal.mysp.test" as a host header to your SharePoint web application in IIS. ...
As a rule of thumb you can say that every URL that ends up in the browser address bar anywhere should be a public URL, therefore a separate zone has to be created. As a good practice, each zone should have its own separate IIS website so you can configure different IIS-related settings like host headers, SSL certificates etc. The public URL is what's being ...
This can be achieved by Extending each of the web applications instead of specifying AAMs only. The steps from where you are now would be:
On each web app, remove the AAMs leaving the default one only
On ISS Remove IIS bindings for the deleted AAMs on each of the SharePoint servers for the respective web sites
On Central Administration => Manage Web ...
they are different things:
Extended Web Application:
If you want to expose the same content in a Web application to different types of users by using additional URLs or authentication methods, you can extend an existing Web application into a new zone. When you extend the Web application into a new zone, you create a separate Internet Information Services (...
Here's a couple of options for you:
In Central Admin, go to your Search Service Application (Content SSA if you use FAST Search for SharePoint) then navigate to Server Name Mappings and create one. Set the "Address in index" field value to your Extended zone url (the one configured to be crawled in the content source) and set the "Address in search results" ...
If you want to set different port to your application, first go to IIS -> your site -> bindings -> add binding for new port.
Go to Central Administration -> Application management -> Configure alternate access mappings -> Add Internal URLs -> here set your alternative name.
Also, remember to configure your DNS service or hosts file, so browser is ...
We finally figured out the problem with this one.
We had given Full Read permissions to NT AUTHORITY\Authenticated Users for All zones in User Policy of the web applications in question. I am not sure of the reason for giving this. We removed it. Then, a full crawl fixed the issue.
You can achieve this using Host Named Site Collections.
Microsoft SharePoint Foundation 2010 supports both path-based and
host-named site collections. The primary difference between path-based
and host-named site collections is that all path-based site
collections in a Web application share the same host name (DNS name),
and each ...
Okay. finally, I found a article and it helped me right away...
Went to "Virtual Network Editor" from my host computer (found under VMWare menu)
Change the IP address for the NAT subnet ip to 192.168.10.0
Followed the article above for more on NAT ...
If the web application is set to use a specific port, you will be bound to that port even with a host header. So simply put, if you want to have http://intranet.domainname.com then you have to have the web application available on port 80.
Using host headers you can have lots of unique names available on the same server, so there really is no reason not ...
You can achieve this using Alternate Access Mapping:
On the Alternate Access Mappings page (Central Administration), click Edit Public URLs.
If the mapping collection that you want to modify is not specified, then choose one.
In the Alternate Access Mapping Collection section,
click Change alternate access mapping collection on the Alternate Access Mapping ...
If you changed the public URL in AAM & configured the IIS website to use SSL it will work without extending to a new website. However, whenever you will add a new webserver SharePoint will configure the original IIS settings that it knows about. That's why it's so important to specify the right public url & host header upon creation of a new web ...
If they are in the same web app, you could technically access PWA via http://sharepoint/pwa.
If so, you can add a DNS entry to point http://project to that server. Then in IIS manager you can add a second binding to the web app. Then you can access http://project/pwa.
Note: Because they are the same web app, you could technically access them from either ...
When you extend a SharePoint web application, you are telling SharePoint to go to IIS and create a new site, but SharePoint will use it to show the same content. You would normally do that to support different security, authentication and URLs between an Internet site, Intranet and Extranet, for example.
When you add a host header it is equivalent to going ...
Here are the steps:
make sure you have valid DNS entry for Local.xyz.com, A record entry for the DNS.
Service Account(domain Account) required which will run the App Pool of new Web App.
Now login on the Central Admin with Farm Admin account
go to Central Admin > Application Management > Manage web Application > from Ribbon Select New
Fill this form with ...
Do not use a redirect. Set your AAM to only https://, and then use the URL rewite module in IIS to rewrite http requests to https. There are guides (http://pcfromdc.blogspot.com/2013/10/how-to-redirect-from-http-to-https-with.html) out there to use the GUI, but I find editing the web.config file be easiest.
Install the URL Rewrite module for IIS and then ...
Also note that adding a new AAM does not automatically create the IIS bindings.
You will need to configure them manually (select the web site in IIS and add the new binding) as they are only created if you extend the web application (which would probably be better in your case).
There is actually a pretty simple solution. Merely have your DNS folks whip up a new DNS entry (like http://sharepoint07.domain.com - note the 07 in there), point that to your current 07 server and then add that as the URL for one of your Zones in your Alternate Access Mappings( I.E. Intranet/Internet/Extranet/Custom).
When the migration happens, http://...
Well, at last I found out what is happening. What I didn't know is that this Datapower was terminating SSL requests and forwarding in HTTP.
The idea found here.
Off-box termination of SSL is when a proxy server terminates an SSL request and then forwards the request to a Web server by using HTTP.
I asked to the colleague that manages the Datapower and ...
Try set it up as follows (ripped from our internal documentation - and assign the self signed cert described above)
Setup Alternate Access Mappings
Open SharePoint 2010 Central Administration
Click Application management
Click Configure alternate access mappings under Web Applications
Click Edit Public URLs (this is on the blue menu bar)
For Alternative ...
The behavior is normal as the AAM doesn't know about your redirect, therefore the Workflow engine is not able to populate the proper Url. You should either use a Reverse'Proxy (e.g. ForeFront TMG, ISA 2006 ) that could automatically change your HTTP to HTTPS or Extend the Web Application to use HTTPS too.
Besides you can make also enable the "Configure ...
You're not supposed to change the IIS settings SharePoint thinks it control in IIS manager (at least not without telling sharepoint).
SharePoint notices that you access it through an unknown zone so it redirects you to the default zone which has the url http://oldurl
So please go into AAM and tell sharepoint what you did :-)
It sounds as though you understand the concept of Web app extension so there isn't too much I can add really.
Something that hasn't been mentioned is the fact that extension creates an additional IIS site. You may wish to configure this site in a different manner to the original, e.g. configure an SSL certificate for access over the Internet or change ...
I think there can be several sources of the problem, if you URL stops working
something is wrong with your DNS server
someone changed IIS bindings
someone changed mappings in Central Administration
About the IIS settings, look into Bindings of your website. Right-click on website and choose Edit bindings. Also go to Central Administration > Application ...