Let’s consider the following scenario:

• You want to have an application at the following URL: https://publishing.contoso.com
• You also want to have an application at : https://bi.contoso.com

You might think about having the second one hosted at port 81. In this case, you will never be able to provide the URL you were thinking about as the Host entry in DNS will direct your requests to the default 80 port. The only way to go would be to have both applications at the same port, 80 that is.

Very basic but it also looks like very confusing for some of my customers. My customer’s question was “is there a way to have a web application on port 81 while having the URL for this site being “www.mycustomer.com” ?". So, the answer is NO.

Let’s have a look at how to enable such a scenario:

Create a new web application:

$DatabaseName = "WSS_Content_publishing"
$Port = 80
$URL = "https://publishing.contoso.com"
$HostHeader = "Publishing"
$AppPoolName = "Publishing"
$AppPoolAcct = "CONTOSO\AppPoolsAcc.svc"


New-SPWebApplication -Name $Name -Port $Port ‘
-URL $URL -HostHeader $HostHeader -ApplicationPool $AppPoolName ‘
-ApplicationPoolAccount $AppPoolAcct -DatabaseName $DatabaseName

Create the second one:

$DatabaseName = "WSS_Content_bi"
$Port = 80
$URL = "https://bi.contoso.com"
$HostHeader = "BI"
$AppPoolName = "BI"
$AppPoolAcct = "CONTOSO\AppPoolsAcc.svc"


New-SPWebApplication -Name $Name -Port $Port ‘
-URL $URL -HostHeader $HostHeader ‘
-ApplicationPool $AppPoolName -ApplicationPoolAccount $AppPoolAcct -DatabaseName $DatabaseName

Noticed they are both on the same port ? The difference is they both have host headers and these ones are different !

Next step would be to add Host entries (A records) in DNS for each of the web applications.

That’s it for the web applications.

The good thing is you can do the same at the site collection level.

This capability was already there for SharePoint 2010, however Microsoft now recommend you create host-named site collections and not path based site collections. In SharePoint 2013 some limitations were addressed and the scalability has been improved.

For instance:

• the new Set-SPSiteUrl has been introduced: it allows you now to add or change an URL mapping for the site.
• you can now add multiple URLs to host-named site collections. URL will be mapped to one of the 5 zones which are the same as for a web applications. But you can add multiple URLs to one zone. In SharePoint 2010, the capability was limited to one URL that was added to the Default zone.

One additionnal recommendation would be to NOT host your host-named site collections in different web applications. This is feasible but management would be quite complex. So, a best practice would be to host your host-named site collections in one dedicated web application and configure DNS to send  request to a “wildcarded” host entry like “*.contoso.com” to the web application hosting your host-named site collections. In this case of course, this web application must not have any binding to a particular host header.

Also,, web applications hosting host-named site collections must have a default site collection at the root BUT this root site collection does not need to be linked to a Template. Actually, this one will not be used. Note htat you will need a DNS entry pointing the IP of the web application hosting the host-named site collections.

In a nutshell, I see two key benefits to it:

• you can now have zone settings for host-named site collection (hosters and multitenant admins will be happy)
• you can be a little bit creative and use multiple host names on internet facing websites. As a result, the amount of concurrent downloads will be improved. For instance having “www.contoso.com” and “www2.contoso.com”.

Let’s start from a target variation site where the My-demo-page has been propagated from the source variation:

This is how the page looks like in the source variation site:

Go to the Variations tab (in this case the “Variantes” tab as this site is the “fr-fr” variation label), select the page and click “Create a tranaslation package” for the selected page.

Save the exported file and edit the exported file with Notepad. In this example, there are two translations unit, one for the page title and one for the page content itself.

You can now edit these sections and manually add the translation by adding “target” elements to the translation units:

Once the content of the “target” elements translated, save this file, go back to you target variation Pages Library, click on “Upload Translation” and upload the XLF file.

Publish the page, open it,, the page has now been translated:

So simple is this. Now, this is a very basic example and using Notepad would not be a very convenient way of editing XLIFF translation packages. Most translation agencies make use of Professional XLIFF editors.

You can give this one a try in order to test more complex page and figure out how easy it would be to create translations: https://sourceforge.net/projects/eviltrans/

Also note XLIFF is an industry standard, not a Microsoft thingie: https://en.wikipedia.org/wiki/XLIFF

This was a very basic demo, and as I had a very limited timeframe to demonstrate these features, going to the list of Timer Jobe defintions for my demo application, and manually hitting the “Run Now” button for any single Timer Job Definition was defitely not an option.

Here below is a script that will help you starting these jobs in a correct sequence, this should help you having your hierachy created, your sites and lists, pages and listitems propagated in no time.

Here are the time jobs you need to run and their default Schedule:

This is not very convenient when it comes to demo or development as you obviously would like to have your pages almost immediately available in target variations as soon as you published a page in the source variation.

This would be the obvious execution sequence of the Timer Jobs

• Variations Create Hierarchies Job Definition (unless you created an additional label, this one should not be executed)
• Variations Propagate Sites and Lists Job Definition
• Variations Propagate Page Job Definition
• Variations Propagate List Items Job Definition

Add-PSSNapin Microsoft.SharePoint.PowerShell

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

cls
function runJob($Job)
{
    write-host "Last execution time was:" $Job.LastRunTime
    [Array] $JobHistoryList=$Job.HistoryEntries
    Start-SPTimerJob $Job
    Write-Host "Running Timer Job:" -NoNewline
    Write-Host $Job.DisplayName  -NoNewline -ForegroundColor Yellow
    Write-Host " for web application: " -NoNewline
    Write-Host $targetWebApp.Url -ForegroundColor Yellow
    
    $count = $JobHistoryList.count
    $countNext = $count+1

    while ( $countNext -ne $count)
    {
    [Array] $JobHistoryList=$Job.HistoryEntries
    $count = $JobHistoryList.count
    Write-Host "=" -NoNewline
    sleep 2 
    }
    Write-Host ""
    if ($Job.status –ne "Succeeded")
    {
    Write-Host -f yellow $JobHistoryList[0].status
    Write-Host -f yellow $JobHistoryList[0].ErrorMessage
    }

    else
    {
    Write-Host -f Green $JobHistoryList[0].status 

    }
}

$webAppURL = Read-Host "Web application URL" 
$targetWebApp = Get-SPWebApplication ($webAppURL)

#VariationsCreateHierarchies job
$createHierarchies = Read-Host "Create Hierarchies ? [Y][N]"
if($createHierarchies -eq "Y")
{
    $jobName = "VariationsCreateHierarchies"
    $Job  = Get-SPTimerJob | ?{$_.Name -match $jobName} | ?{$_.Parent -eq $targetWebApp} 
    runJob($Job)
}

#VariationsSpawnSites job
$propagateSites = Read-Host "Propagate sites and lists ? [Y][N]"
if($propagateSites -eq "Y")
{
    $jobName = "VariationsSpawnSites"
    $Job  = Get-SPTimerJob | ?{$_.Name -match $jobName} | ?{$_.Parent -eq $targetWebApp} 
    runJob($Job)
}

#VariationsPropagatePage job
$propagatePage = Read-Host "Propagate pages ? [Y][N]"
if($propagatePage -eq "Y")
{
    $jobName = "VariationsPropagatePage"
    $Job  = Get-SPTimerJob | ?{$_.Name -match $jobName} | ?{$_.Parent -eq $targetWebApp} 
    runJob($Job)
}

#VariationsPropagateListItem job
$propagateListItem = Read-Host "Propagate list items ? [Y][N]"
if($propagateListItem -eq "Y")
{
    $jobName = "VariationsPropagatePage"
    $Job  = Get-SPTimerJob | ?{$_.Name -match $jobName} | ?{$_.Parent -eq $targetWebApp} 
    runJob($Job)
}

Additionally, as you will most probably want to check if the redirection logic is working properly when you created a new variations label, you will also need to change the browser local back and forth. this can be easily done by having a few .reg files at your disposal. This setting is stored in the following key:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\International] @="" "AcceptLanguage"="fr-FR"

Just change the locale to match your variations labels, close and restart the browser and you should be redirected correctly.

The first one, and again it might seem obvious, concerns the configuration database. The failover process documents were just mentioning “log shipping of the databases” without mentioning there are a few databases in a SharePoint farm for whom log shipping is simply not supported. Among these ones, the most obvious one is the configuration database. SO, it looks like this is a quite common assumption that log shipping databases across farms will just exactly duplicate the environments and keep them in sync. This TechNet article is very clear about that: “The configuration database cannot be log shipped to another farm because it contains computer-specific information. You must maintain the same customizations and configuration settings on both farms manually.” Furthermore, site collections you had to your primary farm will not be registered in the configuration database of the secondary farm even though the content databases containing these site collections are log shipped from the primary to the secondary farm.
You have more or less two ways to work it around:

• Manually detach/attach the content databases in the secondary farm to have the newly created site collections registered in the secondary farm configuration database
• Perform these operations by means of a so-called “refresh script”, the same TechNet article provides an example of such a script.

When looking in more details about what is stored in the configuration database, one of the major concerns in my opinion is about the Alternate Access Mappings because you cannot backup these ones. You have to manually export the list of AAMs by means of the stsadm -o enumalternatedomains command. Since these AAMs have to exactly matching between the primary and secondary farm, it might become a serious issue in the disaster recovery process if not properly documented.

Well, there are obviously a lot of other concerns expressed in the article (patch level alignment not to mention…), however I was feeling like it would be important to keep in mind that relying on log shipping only will not provide a robust disaster recovery/failover scenario as assumed by some customers I worked with recently. Not only it will not be robust but simply lead to unsupported scenarios.

The error message displayed is: "RTE_ToggleEnableShortcuts" is undefined.

The patch level of the MOSS environment was12.0.6331

The "RTE_ToggleEnableShortcuts" can be found in the ***_HtmlEditor.js file located under the “\TEMPLATE\LAYOUTS\LCID” folder in the 12 hive.

There is such a file for all deployed language packs as well, additional foldersd are created for each LCID.

The installation language being English, the default file is “1033\HtmlEditor.js”

The first line of this file indicates which LCID uses the file and the patch level the file is related to.

Here is the exact content of the “Coreservermui-en-us.msp” file which is deployed with the December Cumulative Update for MOSS:

It explains why different versions of the file are present, only the default language file will be update by applying the December Cumulative Update.

Resolution

• Replace the file “c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\any_lcid\HtmlEditor.js” with the same file from 1033
  version.
• Additionally, you could realign all servers in the farm, including language packs by deploying WSS/MOSS SP2 and Language Packs for SP2. References can be found in the next section.

Multiple Error entries appear in the Application log of all SharePoint servers of the farms:

The error is raised because the SynAttackProtect registry key has its default value of 1 set up on the SQL server hosting SharePoint ® databases and/or on the SharePoint ® servers in farms

synattackprotect"=dword:00000001

A TCP Synchronize (SYN) attack is a denial-of-service attack that exploits the retransmission and time-out behavior of the Synchronize-Acknowledgement (SYN-ACK) segment during the TCP three-way handshake to create a large number of half-open TCP connections. Depending on the TCP/IP protocol implementation, a large number of half-open TCP connections could do any of the following:

• Use all available memory.
• Use all possible entries in the TCP Transmission Control Block (TCB), an internal table used to track TCP connections. Once the half-open connections use all the entries, further connection attempts are responded to with a TCP connection reset.
• Use all available half-open connections. Once all the half-open connections are used, further connection attempts are responded to with a TCP connection reset.

To create a large number of TCP half-open connections, attackers send a large number of SYN segments, each from a spoofed IP address and TCP port number. Each spoofed IP address and TCP port number are for a process that does not respond to the SYN-ACKs being sent by the attacked host. SYN attacks are typically used to render Internet servers inoperative.

To mitigate the impact on a host experiencing a SYN attack, TCP/IP minimizes the amount of resources devoted to incomplete TCP connections and reduces the amount of time before abandoning half-open connections. When a SYN attack is detected, TCP/IP in Windows Server 2003 and Windows XP lowers the number of retransmissions of the SYN-ACK segment and does not allocate memory or table entry resources for the connection until the TCP three-way handshake has been completed.

You can control SYN attack protection through the SynAttackProtect registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (type REG_DWORD). You set SynAttackProtect to 0 to disable SYN attack protection and to 1 to enable it.

For TCP/IP in Windows XP (all versions) and Windows Server 2003 with no service packs installed, SynAttackProtect is set to 0 by default. For TCP/IP in Windows Server 2003 SP1, SynAttackProtect is set to 1 by default.

For more information about TCP connection behavior and related registry entries, see

· Microsoft Windows Server 2003 TCP/IP Implementation Details

· https://technet.microsoft.com/en-us/library/bb878132.aspx

The issue is also extensively described in this blog post: https://blogs.msdn.com/sql_protocols/archive/2006/04/12/574608.aspx

I did not performed in-depth analysis in order to identify the elements that are the causing the packets backlog queue (which is max to 200 by default on w2k3 standard server), to be exhausted.

Depending on the OS version, the default setting for the SynAttackProtect might be different:

OS version	\SynAttackProtect default value
Windows Server 2003 RTM	0
Windows Server 2003 SP1	1
Windows Server 2003 SP2	1
Windows Server 2003 R2	1

The solution for this would be modifying the SynAttackProtect registry key on each server concerned by the issue, playing an active SharePoint ® role or a role in the general connectivity between servers in SharePoint ® farms.

Microsoft Windows Server 2003 Service Pack 1 and higher implements a security feature that reduces the size of the queue for concurrent TCP/IP connections to the server. This feature helps prevent denial of service attacks. Under heavy load conditions, the TCP/IP protocol in Windows Server 2003 may incorrectly identify valid TCP/IP connections as a denial of service attack. For more information see this

324270: How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003: https://support.microsoft.com/kb/324270

Applications or services connecting to SQL could experience network errors due connection forcibly closed by the OS like "General network error".

Recommendation

On Windows 2003 SP1+ system with high number of TCP connections and/or heavy TCP traffic, set to 0 the registry key value "SynAttackProtect" under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" as explained in these two KB articles:

A BizTalk Server Host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents

https://support.microsoft.com/?id=899599

910228: SQL Server 2005 Readme and installation requirements

https://support.microsoft.com/kb/910228

Hardening servers only might result in a situation where the customers facing this issues would put a SQL box directly connected to an unsecure network.

Conclusion

• Set the SynAttackProtect key value to 0 on the affected servers
• Communicate the issue to the network infrastructure team to ensure this kind of attack is addressed on the “Layer 3” TCP Transport level

Solutions are deployed in one of two ways: either locally or by using a timer service.
This applies both to new deployments, as well as to deployments of solution upgrades.
Both local and timer-based deployments can be triggered either by using command-line instructions or programmatically by using the object model.

Local deployments that are initiated from the command line by a user with administrator privileges run in the context of the administrator. If initiated by using the timer service, however, the deployment runs in the context of the timer job itself, which uses administrator pool account credentials. Either set of credentials should be sufficient to read and write to the configuration store.

Local Deployment

In a local deployment, solution files are deployed only to the computer from which the deployment operation was initiated. Under this scenario, the solution is not marked as "deployed" in the configuration database until the solution files are deployed to all applicable servers in the server farm. Then, in the case of new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

Timer Service Deployments

In deployments that use the timer service, the deployment creates a timer job. This timer job is picked up by the timer service on each Web server in the server farm. The timer job uses the Windows SharePoint Services Administrative Web service to access appropriate privileges to deploy solution files to each computer.

Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).

For upgrades, the deployment has no impact to the end user experience. The new versions of the solution files do not overwrite the old files; therefore, if a computer is restarted, or the upgrade process is aborted, the servers are synchronized with their other data files.

Finally, for new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

I recently cam acroos the following issue:

stsadm -o deploysolution -name "my_solution.wsp" –url "https://server.somedom.net" -local –allowGacDeployment

This command fails, the following message is displayed:

This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.

While this command completes successfully

stsadm -o deploysolution -name "my_solution.wsp" -local –allowGacDeployment

When looking at the manifest.xml and feature.xml files for this package, we can figure out this package has no “resources”, which means no content has to be copied to a particular web application virtual directory.

The bottom line is that if your solution specifies elements (a.k.a. "resources") that need to be merged into a Web.config file (i.e. "for a Web application") then you must specify the url parameter. If your solution does not have an assembly or if your solution contains workflows, then you cannot specify the url parameter.

The same goes for packages that would not contain an assembly.

This corruption was only discovered after several weeks, and unfortunately the earliest usable backup dates from weeks ago. On top of this, the transaction logs that could be used to “replay” all database transactions starting from this last good backup, are also unusable.

The first thing to do would be to checkout the I/O subsystem - as it looks like that is what caused the problem. The damaged pages are contiguous, which usually is a symptom of I/O subsystem failure.

This customer came to me with questions about the way to fix this issue. The answer is pretty obvious: restore the last valid backup. Any operation on the MOSS databases would totally unsupported, which means that DBCC REPAIR_WITH_DATA_LOSS scenario may not be applied here.

I must stress that the only official and supported solution Microsoft is able to provide at this point, is to revert to the last usable database.

Basically, the only thing I have been able to do for this customer is helping them evaluate which kind of content is affected by the corruption.

So, what I have to do is identify which content is excatly affected by the corrption.

When looking at the DBCC CHECK output, I have the following:

DBCC results for 'AllDocStreams'.

Msg 8928, Level 16, State 1, Line 1

Object ID 293576084, index ID 1, partition ID 72057595341373440, alloc unit ID 72057594043957248 (type LOB data): Page (1:1760824) could not be processed. See other errors for details.

Msg 8965, Level 16, State 1, Line 1

Table error: Object ID 293576084, index ID 1, partition ID 72057595341373440, alloc unit ID 72057594043957248 (type LOB data). The off-row data node at page (1:1760824), slot 0, text ID 813336166400 is referenced by page (1:1760788), slot 0, but was not seen in the scan.

Msg 8928, Level 16, State 1, Line 1

Object ID 293576084, index ID 1, partition ID 72057595341373440, alloc unit ID 72057594043957248 (type LOB data): Page (1:1760825) could not be processed. See other errors for details.

Msg 8965, Level 16, State 1, Line 1

Table error: Object ID 293576084, index ID 1, partition ID 72057595341373440, alloc unit ID 72057594043957248 (type LOB data). The off-row data node at page (1:1760825), slot 0, text ID 813336166400 is referenced by page (1:1760788), slot 0, but was not seen in the scan.

Msg 8929, Level 16, State 1, Line 1

Object ID 293576084, index ID 1, partition ID 72057595341373440, alloc unit ID 72057595387314176 (type In-row data): Errors found in off-row data with ID 813336166400 owned by data record identified by RID = (1:1916095:6)

There are 62627 rows in 855 pages for object "AllDocStreams".

CHECKDB found 0 allocation errors and 5 consistency errors in table 'AllDocStreams' (object ID 293576084).

Based on this information, one thing we should do is to have a look at the rows that are damaged using the DBCC PAGE command

dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])

The filenum and pagenum parameters are taken from the page IDs that come from various system tables and appear in DBCC or other system error messages. A page ID of, say, (1:354) has filenum = 1 and pagenum = 354.

The printopt parameter has the following meanings:

· 0 - print just the page header

· 1 - page header plus per-row hex dumps and a dump of the page slot array (unless its a page that doesn't have one, like allocation bitmaps)

· 2 - page header plus whole page hex dump

· 3 - page header plus detailed per-row interpretation

Knowing this we run the following command for instance:

dbcc traceon (3604)

go

dbcc page (your_content_database_name, 1,1760824,3)

Go

dbcc traceon (3604)

go

dbcc page (your_content_database_name, 1,1760825,3)

go

Running this operation will dump the corrupted pages content. Based on this output we should able to identify which particular piece of content suffers from corruption.

The analysis of the output should provide valuable information in order to have a more precise evaluation of the risks and have a better understanding of the impact on the entire MOSS environment.

Having a look at the content of the SQL pages dumps, we have been to figure out the corrupted items are not always the current ones. It explains why the last published item is still accessible. However, when trying to access the version history of the item through the UI, we get an “unknow error” message due to the corruption of some of the item versions.

In no case it would be feasible to delete the database rows containing the corrupted versions of the item without globally breaking the integrity of the item.

This is actually an easy scenario since the corruption affects data stored in the data rows (IndexID 1 in the DBCC Check output). You might be facing some cases where the corruption affects the page header (IndexID –1 in the DBCC CHeck output) itself as below

Consider how a SQL page is structured:

The clustered index is how the data is arranged physically; therefore there can be only one clustered index for a given table.

Internally if we need to add data, we do not shift everything on the page in order to insert it in the right place, we just use the slot array. Because there is only one slot array, this is the “physical” order of the data.

The corruption can affect the Page header, the Data rows or the Row offset array. Unfortunately, it looks like the index itself might be corrupted which is a scenario which makes the processing of the SQL page dumps way more difficult and complex: using DBCC IND in order to identify which page belongs to which object and so on…

In the latest example, some corruption occurred in the header and row offset array of the page as well. It means the following command cannot be run with the printopt parameter set to 3, which was the option that made the relevant information about particular SharePoint items available to us in the Horizon scenario:

dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])

Not being able to use the 3 switch is an additional demonstration of the fact that the data “metadata” is corrupted and the interpretation of the data is subsequently impossible.

Without being able to identify which SharePoint items are affected by the corruption, performing a repair on the database will leave this one in a state where the impact of the operation cannot be determined at all since we cannot match this data to any SharePoint equivalent object.

Conclusion

As a reminder, beyond the concerns expressed in this post, modifying the database schema or database structures is unsupported for additional reasons. Changes that you make to the database contents may be overwritten when you install updates or service packs for Windows SharePoint Services, or when you upgrade an installation to the next product version.

Regarded of the supportability, I would strongly advise to evaluate and implement a strong backup strategy, efficient proactive monitoring and a well-tested Disaster Recovery Planning in order to avoid or mitigate similar situations you might have in the future.