Error 404 Page Not Found after Upgrade to BP 5.0

This question is answered

Hi everyone,

Does anybody have encountered this issue before after their upgrade from BP 4.0 to BP 5.0 ? the SharePoint was not changed, still running on WSS 3.0. This BP site was perfectly working  before. According to the MS upgrade doc, this is the most straightfoward and safe way to upgrade the BP to be compatible with GP 2010. We upgraded our GP2010 almost 2 years ago, but the BP was left running on the version 4.0 and had no issues so far. The problem was that we added new companies to our GP system and the BP doesn't see them, or rather can't work with them because the BP configuration wizard cannot be executed in that version of GP as back-end, thus the upgrade of the BP.

After the upgrade, most of the SharePoint stuff was loading fine, but when it comes to open the BP specific web-parts, the browser just returns an error 404 Page Not Found. The browsing of the BP is made over a secured SSL link/url. When altering the IIS security configuration to allow non-secured connections, and using the regular http:// over the port 82 (where the BP site is installed), the web-parts are opening just fine. So this seems clearly to be an issue with the IIS security config and the SSL. But nothing has been changed on this side, only the BP was uninstalled from the version 4.0 and the new BP 5.0 was setup by using the installation program. This shouldn't affect the IIS settings, but I suspect that some of the ASPX files that have been replaced by the setup are no longer recognized to be used with the SSL security protocol.

Can anybody shed a light on this ? I've looked everywhere on the net about SSL related issues with SharePoint, but none of them deal with Business Portal web-parts...

Thanks in advance for the help.

--
Enjoy the Life
+-+-+-+-+-+-+-+
Beat BUCHER
Dynamics GP 2010R2 Business Analyst
www.fti-ibis.com
+-+-+-+-+-+-+-+

Verified Answer
  • Hi Rob,

    The issue had nothing to do with the URL or the configuration file...

    The solution to my problem was pretty tricky and I had to sleep over actually two nights before I had a light bulb coming up and started to search in a complete opposite direction..

    As some may not know, but the BP 5.0 setup process taps apparently into the IIS settings in some ways (or maybe it was just pure coincidence, but I don't believe in coincidences during those times :-) ).  So I started to search about issues related between ASPX pages and SSL / https protocol... After a few minutes I came across an article from Microsoft about 404 errors related to the HTTPS protocol. Though it was not ASPX specific, I said myself there is not much to lose, so let's try this out.

    support.microsoft.com

    it's all about the port 443 binding in IIS 6.0 and the IP address of the BP server.. Though this hasn't changed in any way in my case, because the upgrade was done inside on the existing BP 4.0 system, I'd have been surprised that anything related to the SSL security could have changed in IIS, but somehow it did.  So I followed the instruction from the KB article and cleared out the current settings for the SSL port binding.

    Be aware that the article mentions to retrieve an object number '1' but this may actually not working on your system... this is what I got back on my server :

    The path requested could not be found.

    ErrNumber: -2147024893 (0x80070003)

    Error Trying To GET the Object (GetObject Failed): w3svc/1

    So looking what other command options were available for 'adsutil', I found the ENUM option :   adsutil ENUM /P W3SVC

    This will return you a list of the current define bindings in your system. You can safely ignore the /w3svc/AppPools, /Filters and /Info objects, but there will be 1-n other numbers depending on the number of AppPool sites you have in your IIS.  Just write down those numbers and repeat the 'get' option with every number. If any of those are returning a binded IP address, then use the 'set' option from the article to wipe it out.

    Run an IISReset on the command line prompt to restart your IIS services and go into the Web Site properties. Check the SSL settings under 'Advanced...' Web Site Identification, your default IP has probably been removed. Just add the port 443 back with the default "All Unassigned" and you should be fine. Recycle your Application Pools site and test your BP web parts. They should now load correctly and give you fully access to the BP.

    Thanks anyway for the reference about the BusinessFramework.config file, now at least I know where to look to change the GP database name... that is a pretty annoying bug when you move your GP data server to another instance and cannot reconfigure BP to point to the new one...

    On the same note, I opened a ticket with the tech support, because during the upgrade some of our existing GP company were not updated properly and I suspect some version mismatch causing data access issues now.

    --
    Enjoy the Life
    +-+-+-+-+-+-+-+
    Beat BUCHER
    Dynamics GP 2010R2 Business Analyst
    www.fti-ibis.com
    +-+-+-+-+-+-+-+

All Replies
  • Beat,

    I haven't seen this exactly, so I can only guess.  I'd start by checking the BusinessFramework.config file in the Inetpub\......\bin folder.  See if the url's in there are correct.

    Thanks

    Rob

    Rob Bernhardt [MSFT]

    This posting is provided "AS IS" with no warranties, and confers no rights.

  • Hi Rob,

    The issue had nothing to do with the URL or the configuration file...

    The solution to my problem was pretty tricky and I had to sleep over actually two nights before I had a light bulb coming up and started to search in a complete opposite direction..

    As some may not know, but the BP 5.0 setup process taps apparently into the IIS settings in some ways (or maybe it was just pure coincidence, but I don't believe in coincidences during those times :-) ).  So I started to search about issues related between ASPX pages and SSL / https protocol... After a few minutes I came across an article from Microsoft about 404 errors related to the HTTPS protocol. Though it was not ASPX specific, I said myself there is not much to lose, so let's try this out.

    support.microsoft.com

    it's all about the port 443 binding in IIS 6.0 and the IP address of the BP server.. Though this hasn't changed in any way in my case, because the upgrade was done inside on the existing BP 4.0 system, I'd have been surprised that anything related to the SSL security could have changed in IIS, but somehow it did.  So I followed the instruction from the KB article and cleared out the current settings for the SSL port binding.

    Be aware that the article mentions to retrieve an object number '1' but this may actually not working on your system... this is what I got back on my server :

    The path requested could not be found.

    ErrNumber: -2147024893 (0x80070003)

    Error Trying To GET the Object (GetObject Failed): w3svc/1

    So looking what other command options were available for 'adsutil', I found the ENUM option :   adsutil ENUM /P W3SVC

    This will return you a list of the current define bindings in your system. You can safely ignore the /w3svc/AppPools, /Filters and /Info objects, but there will be 1-n other numbers depending on the number of AppPool sites you have in your IIS.  Just write down those numbers and repeat the 'get' option with every number. If any of those are returning a binded IP address, then use the 'set' option from the article to wipe it out.

    Run an IISReset on the command line prompt to restart your IIS services and go into the Web Site properties. Check the SSL settings under 'Advanced...' Web Site Identification, your default IP has probably been removed. Just add the port 443 back with the default "All Unassigned" and you should be fine. Recycle your Application Pools site and test your BP web parts. They should now load correctly and give you fully access to the BP.

    Thanks anyway for the reference about the BusinessFramework.config file, now at least I know where to look to change the GP database name... that is a pretty annoying bug when you move your GP data server to another instance and cannot reconfigure BP to point to the new one...

    On the same note, I opened a ticket with the tech support, because during the upgrade some of our existing GP company were not updated properly and I suspect some version mismatch causing data access issues now.

    --
    Enjoy the Life
    +-+-+-+-+-+-+-+
    Beat BUCHER
    Dynamics GP 2010R2 Business Analyst
    www.fti-ibis.com
    +-+-+-+-+-+-+-+