ArntK and MISMonkey,

Could either of you provide the values in your PortalAlias table. I think I located the problem in the upgrade logic, but in order to verify, I need to know what portal alias value is causing the issue.

Hmm.... this does not really explain it. I was looking at this logic in upgrade.vb - UpdateApplication():

                For Each objAlias In arrAliases
                    'For the alias to be for a child it must be of the form ...../child
                    If objAlias.HTTPAlias.LastIndexOf("/") <> -1 Then
                        childPath = ApplicationMapPath & "\" & objAlias.HTTPAlias.Substring(objAlias.HTTPAlias.LastIndexOf("/") + 1)
                        If Directory.Exists(childPath) Then
                            'Folder exists App/child so upgrade

                            'Rename existing file
                            System.IO.File.Copy(childPath & "\" & glbDefaultPage, childPath & "\old_" & glbDefaultPage, True)

                            ' create the subhost default.aspx file
                            System.IO.File.Copy(Common.Globals.HostMapPath & "subhost.aspx", childPath & "\" & glbDefaultPage, True)
                        End If
                    End If
                Next

This is legacy logic to replace old child portal default.aspx files with a newer format. It tries to determine child portals based on the existence of "/" in the portal alias. I was thinking there may be a way for a portal alias to end in "/" - which would then result in the root default.aspx getting replaced. Based on your portal alias values, this does not seem to be the case. I will need to continue investigating.

The only difference between a "Host" or Parent portal and a child portal is that the child portal has a subfolder with a default.aspx page that redirects to the parent default.aspx (adding the appropriate querystring parameter).

Therefore the answer is yes.