This initial sign in prompt is required because the O365 Azure AD sign in page provides the KMSI (Keep Me Signed In) functionality that’s required in order for the SPO FedAuth cookie to be made persistent so that it can be shared across sessions of browser, Office, Explorer, etc. If the FedAuth cookie isn’t made persistent, certain functionality such as opening a SharePoint List using Windows Explorer View may fail with the error

We're having a problem opening this location in File Explorer. To open with File Explorer, you'll need to add this site to your Trusted Sites list and select the "Keep me signed in" check box when you sign in to the SharePoint Online site. For more information,
see https://support.microsoft.com/kb/2629108  

The use of Smart Links (https://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx)  is only way to get around this initial sign-in prompt. HOWEVER, when using smart links to access O365, you are forcing clients to bypass the O365 Azure AD sign in page, which prevent them from getting a persistent FedAuth cookie. Therefore they will run into additional prompts and errors when using Office applications that interact with SPO and/or when attempting to open a SharePoint list using the Windows Explorer View (as mentioned above).
For this reason, my recommendation is that smart links not be used and that the default sign-in process/behavior remain as is.This will prevent issues as the one mentioned above, as well as other additional sign in prompts when using applications that interact with SPO and O365.

 To make things as stream line as possible, the following settings can be made on user machines (in IE).-  

     
-   Have *.<yourdomain>.com and https://login.microsoftonline.com added to my Trusted Sites list in IE

-   Have “Automatic logon with current user name and password” selected in the security settings for the Trusted Sites Zone

-   Select “Remember Me” when signing into O365 for the first time, so Windows Credential Manager stores the logon credentials for your adfs sts server ( ie https://sts.contoso.com) you can verify this in Control Panel/ User Accounts/Credential Manager

-   Check the box “Keep Me Signed In” when signing into O365

 In testing these settings, the behavior I get is that I only have to type in my user name in the initial sign-in prompt. As soon as I click in the password box, a realm discovery is made and my user name/password (that I’m logged into windows with) is them passed to my ADFS STS server and I’m then in O365. I do not have to type in the password. I only have to type in my user name.

Yes the MySite/SkyDrive links will work fine...However certain operation like clicking on a users name under the "Modified By" column in an on-prem library

will fail with the following error

This is because SharePoint on-prem is passing the user context to Office 365 as accountname=DORADOJOES\elib

https://proseware-my.sharepoint.com/Person.aspx?accountname=Contoso\elib

 rather than accountname=i:0#.f|membership|elib@doradojoes.com

https://proseware-my.sharepoint.com/Person.aspx?accountname=i:0#.f|membership|elib@contoso.com

To avoid this issue, you may want to implement a solution similar to the one below in which we provisioned a custom.aspx page (sample code below) in the on-premises SharePoint farm that performs a string manipulation against the accountname so its formatted properly before being passed to O365

-    Drop that custom.aspx page into the Layouts directory on all on-prem SP servers,

-    Then rather than pointing to https://<tenantname>-my.sharepoint.com url as a Trusted MySite Host Location, you point to https://<onpremMySiteHost>/_layouts/custom.aspx as the Trusted MySite Host Location instead.

NOTE: you will need to change <tenantname> to the actual name of your O356 tenant

ex. "https://contoso-my.sharepoint.com/Person.aspx?accountname="   

<html>
 <head>
 <script language="CS" runat="server">
 void Page_Load(object sender, System.EventArgs e)
 {
 try
 {
 string account = Request.QueryString["accountname"];
 if(account != null)
 {
 // Extract domain and name of user from the account name
 int stop = account.IndexOf("\\");
 string domain = account.Substring(0, stop);
 string user = account.Substring(stop + 1, account.Length - stop - 1);
 
 // Construct the SPO URL to redirect to
 string spoUser = String.Format("i:0#.f|membership|{0}@{1}.com", user, domain);
 string spoUrl = "https://<tenantname>-my.sharepoint.com/Person.aspx?accountname=" + Server.UrlEncode(spoUser);
 
 // Redirect to profile page in SPO
 Response.Redirect(spoUrl);
 }
 }
 catch
 {
 // Handle error as necessary
 throw;
 }
 }
 </script>
 </head>
 </html>
 

Go Cloud!!!

https://contoso-my.sharepoint.com/personal/joev_contoso_com/_layouts/sitehealthcheck.aspx

 Make sure no issues are reported

3) In this example, notice the custom and additional lists and calendar that have been added to my My Site
We’ll observe what happens to them after the upgrade process is complete.

 Then click "Start Now" in the pink ribbon which take you following 

If you click Try a DEMO UPGRADE you get

 And then

 If you click Upgrade This Site Collection, you get

 

Click I'm ready and

If any errors or warnings are generated you can click the log file link to get more detail 

In this example, from the log file we see that the upgrade process attempts to remove a webpart that doesn't exist so we can ignore this warning.

When user clicks "Let's see the new site" they are taken to their upgraded My Site

Notice that the Custom list, Added Calendar, and Test Library 1 I had added to my original My Site no longer appear in the quick launch area once the site is
upgraded

To access any custom lists, libraries, etc after the My Site upgrade, click Site Actions (gear icon) and select Site Contents

And the custom lists and libraries are there

 
At this point, if the user has SkyDrive Pro installed on their PC, they can click Sync in the upper right corner of their My Site. This will launch the Sky Drive Pro client
on their PC prompting them for credentials.

Once they enter their credentials for SharePoint Online, they will then have the SkyDrive Pro drive appear in Windows Explorer on their
PC in which they can sync files to/from their SharePoint Online SkyDrive Pro

Also, all pre-existing SP2010 sites will look the same after a tenant is upgraded from Wave14 to Wave15. Once the upgrade is done, site collection admins will need to upgrade each of their sites to take advantage of all the new features of SharePoint. 
 Its important to note this is a required step that should be completed within three months of the upgrade. If you don't get around to it, the MS Online Team will trigger the upgrade automatically at some point--They will contact you before they do so.

 But what about brand new Wave15 tenants (that are not upgrade from Wave14)?
What I've found through testing and PowerShell (the SPO Management Shell), is that new Wave15 tenants do not provide the ability to allow creation of old version (wave14) site collections.
First, from the SPO Admin Center, under Settings, the "Global Experience Version Settings" setting has "Prevent creation of old version site collections" selected, and the  Allow creation of old version site collections" is grayed out. You cannot modify this setting via the SPO Admin Center.

Using SPO Management Shell, even though attempting to change the minimum compatibility level by running Set-SPOTenant -minCompatibilityLevel 14 appears to succeed, as shown below, the setting will not take affect. Leaving the minCompatibilityLevel set to 15

• Verify what the displayname looks like
• Verify what happens when theres a duplicate sitename and list/email name
  
  
  
• Webapp - https://webapp1
• Sitename and URL  - teamsite  https://webapp1/sites/teamsite
• List name - List1
• List email name - list1@SP2010-1.seafox.com 
    

 
Auto created contact in AD 

The "Automatically update email addresses based on email address policy" setting must be checked/enabled
on SP mail contact in order for it to appear in GAL

The name will then appear in the GAL in the format of site name

Now what happens when trying to assign the same email name (list1@sp2010-1seafox.com)  to a different list in SharePoint  So in this scenario we have https://webapp1/sites/teamsite/list1 (where list1 has email name = list1) https://webapp2/sites/teamsite/list1
The follow error will occur if we try to set email name on  https://webapp2/sites/teamsite/list1  to" list1" which prevents duplicate emails names from being created

However if I give I give the second List1 list unique email name like "list2" it will be created successfully

 So in this scenario we now have
https://webapp1/sites/teamsite/list1  (where list1 has email name = list1)
https://webapp2/sites/teamsite/list1  (where list1 has email name = list2)

 We end up with duplicate entries in the GAL as below

This is because the display name is created/concatenated from the site name and list name as shown below

If a site contains an item with a large ACL, does that mean the entire site cannot be crawled?

Or the entire list that the item resides in cannot be crawled?

or only the item itself?

Since current documentation on this matter is vauge at best, instead of debating this to death we decided to setup a test lab and see for ourselves what the actual affect on crawling really is.

Below is the result from our testing:

Below is a crawl log from testing performed with an overloaded ACL inwhich 5000 domain users where given full control to one document item in a document library. The document https://teampolar/testdocs/test1.doc is our ACL overloaded doc.

Afterward we ran an incremental crawl.

A screenshot of the crawl log is below.

the ".... and monitoring.doc" (just above it in crawl log) is in the same https://teampolar/testdocs document library and as you can see we can crawl it fine, along with everything else currently in the testdocs library and site. 

So looks like the only thing that we can't crawl is the specific item(s) that have > 1800 ACEs as the Site ACL itself contained the 5000 user objects with the grayed out "Limited" access right which is typical when a user is given explicit access to an item within the site.

But in crawl log screenshot below, you can clearly see that the only items we are not able to crawl is the particular  item that has the large ACL.

LargeACL_CrawlLog.jpg

- You then take that backup and restore it to another hostheader site collection called hhsitecollection2.contoso.com that you alread have running in your farm

stsadm -o restore -url hhsitecollection2.contoso.com -filename c:\hhsitecollection1.bak -overwrite -hhurl https://<URLofHostHeaderWebApp>

 What you end of with is a site collection that has the Path value "hhsitecollection2.contoso.com" still registered in the SiteMap table of the Configuration database

 ==========================================================================================================

Id	DatabaseId	Path
BE18A48E-5DF9-428B-AD3D-AE3FE064C457	5F9A4A4D-62DF-4D93-A505-2907A7116DB2	hhsitecollection2.contoso.com

 ===========================================================================================================

But has a HostHeader value of "hhsitecollection1.contoso.com" in the Sites table of its content database.

================================================================

Id	HostHeader
BE18A48E-5DF9-428B-AD3D-AE3FE064C457	hhsitecollection1.contoso.com

================================================================

Note that Site's ID remains the same BE18A48E-5DF9-428B-AD3D-AE3FE064C457 in both Dbs

At this point, as long as that contentDb is never detached and reattached, you will never notice a problem as users and tools will still be able to access that site collection using the https://hhsitecollection2.contoso.com URL as they always have.

However major problems will occur once that site collection's contentDb is detached and reattached to the farm.

When that happens,one of two bad things will occur:

1) The site collection is no longer available using its original URL
For example, if an entry for "hhsitecollection1.contoso.com" does not already exist in the SiteMap table of the Configuration Database, once the contentDb is re-attached, Sharepoint will pick up the HostHeader value for the site collection from the contentDb,which is now hhsitecollection1.contoso.com due to the stsadm restore process, and enter it into the SiteMap table (along with other information such as SiteID etc.)
At this point hhsitecollection2.contoso.com  will no longer be accessible via the https://hhsitecollection2.contoso.com URL.
The only accessible URL for hhsitecollection2.contoso.com will be https://hhsitecollection1.contoso.com

Fortunately at this point you can correct the problem by running
stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com  -newurl https://hhsitecollection2.contoso.com

This will reset both the Path value in SiteMap table of ConfigDb and the HostHeader value in Sites table of ContentDb back to hhsitecollection2.contoso.com
and users are back on this site using https://hhsitecollection2.contoso.com

OR  2) The host header site collection becomes orphaned (it exists in the content Db but is no longer accessible)
For example this happens if a Path value of "hhsitecollection1.contoso.com"  already exist in the SiteMap table of the Configuration Database,(because that site collection happens to exist in some other contentDb).
Since Sharepoint doesn't allow duplicate Path values in the SiteMap table of the Configuration Database (for obvious reasons), at this point once the contentDb is reattached to the farm, the https://hhsitecollection2.contoso.com hostheader site collection (which has hostheader value "hhsitecollection1.contoso.com" after stsadm -o restore) will become orphaned. 
It still exists in the content Db but it is no longer accessible via the browser, stsadm, or SP object model)

Recovering orphaned host header site collections
One of the options for recovering these specific types of orphaned host header site collections is:

1. use stsadm - o renamesite to temporarily rename the conflicting host header site collection that is in the farm
In our example we would need to rename the good/working  https://hhsitecollection1.contoso.com   to a temporary name
NOTE: This will take this site out of commission until the rest of the steps are completed

stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com  -newurl https://temphhsitecollection1.contoso.com 

2. Detach and reattach the contentDb that contains the orphaned https://hhsitecollection1.contoso.com 
(Remember its original name was https://hhsitecollection2.contoso.com before the stsadm -o restore and we need to get it back as  https://hhsitecollection2.contoso.com )
So once you reattach its contentDb,  https://hhsitecollection2.contoso.com is now accessible again as https://hhsitecollection1.contoso.com   

3. Rename hhsitecollection2.contoso.com back to its original name

stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com  -newurl https://temphhsitecollection2.contoso.com 

4. Now rename the original hhsitecollection1.contoso.com (that you renamed in step 1) back to its original name
stsadm -o renamesite -oldurl https://temphhsitecollection1.contoso.com  -newurl https://hhsitecollection1.contoso.com 

At this point  https://hhsitecollection2.contoso.com and https://hhsitecollection2.contoso.com should both be available again.

Now how to prevent this problem from occurring in the first place:
Whenever you restore a host header site collection using stsadm, just be sure to run stsadm -o renamesite immediately after the stsadm -o restore process completes.
When doing so, the -oldurl and -newurl parameters you specifiy should both be the hh site collection name that you want to use.

For example:
stsadm -o restore -url hhsitecollection2.contoso.com -filename c:\hhsitecollection1.bak -overwrite -hhurl https://<URLofHostHeaderWebApp>

then once that completes run,

stsadm -o renamesite -oldurl https://hhsitecollection2.contoso.com  -newurl https://hhsitecollection2.contoso.com

This will rewrite the hostheader value in the contentDb to the -url value that you specified in the stsadm restore command (in this case hhsitecollection2.contoso.com)

 ======================================================================================================================

Also on a somewhat related note:
Service Pack 2 for WSS3.0/MOSS introduces the ability to "delete" orphaned site collections by using the new siteid parameter.

C:\>stsadm -help deletesite

stsadm.exe -o deletesite
          [-url <url>
           -deleteadaccounts <true/false>]
          [-force
           -siteid <site id>
           -databasename <database name>
           -databaseserver <database server name>]

Since your dealing with an orphaned site collection the only way to get the siteId is by looking in its content database and getting the "Id" value of the orphaned site collection

In testing I've performed, an orphaned hostheader site collection did not block or cause an SP2 upgrade to fail.
In my testing, both the Farm, and the contentDb I had that contained an orphaned hostheader site collection and was attached to the farm, upgraded successfully.

=============================================================================================================== 

 Providing an update regarding a fix in the June 09 CU that prevents duplication of host header values that are caused when using stsadm to restore host header site collections 

Problem

When restoring a host header site collection from backup to a new host header site collection, the host header value for the restored site collection is still the old sites host header. After restoring the site collection if we detach and reattach the restored site collection's content DB, the restored site collection is no longer accessible and left orphan.

Resolution

Microsoft has produced a hotfix (KB970946) to address this issue. Details of how and where to obtain the hotfix are shown below. 

Related Knowledge Base Articles

The details of the hotfix can be found in the following article:

970946 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): June 30, 2009

Please note that this fix can also be applied by installing the June Server-Package for WSS 3.0.  This fix is detailed in the following article:

971538 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 30, 2009

Additional Information and Recommendations

There is a link on each of the hotfix articles that will allow you to download the hotfixes when you are ready. You can also find detailed, step-by-step instructions for downloading hotfixes by clicking here.

For complete guidance on applying updates please refer to Updates Resource Center for SharePoint Products and Technologies.

Update Steps & Suggestions

To get your SharePoint installation as up-to-date as possible, we recommend that customers install updates in the following sequence (the steps below assume MOSS is installed, if it is not feel free to omit those fixes):

1.      Windows SharePoint Services 3.0 Service Pack 2 (SP2)

2.      The 2007 Microsoft Office Servers Service Pack 2 (SP2)

3.      971620 When you install the 2007 Microsoft Office servers Service Pack 2, the product expiration date is activated incorrectly

4.      971538   Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 30, 2009

5.      971537 Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (MOSS server-package): June 30, 2009

After applying the preceding updates on all servers in the farm, run the SharePoint Products and Technologies Configuration Wizard or the “psconfig –cmd upgrade –inplace b2b -wait” command on each server one at a time. This needs to be done on every server in the farm with SharePoint installed.