Michael's profileMike's RavingsBlogLists Tools Help

Blog


    December 18

    MOSS Load Balanced URL

     

                    One of the fields least understood by someone first coming into MOSS is the Load Balanced URL which if a field required on the “Create Web Application” screen from central administration. It will default to the current server URL and port. If you have worked on a single web front end install, chances are you didn’t even give this field a second look. Chances are of you added another WFE to your farm, you suddenly scratched your head and murmured some type of expletive when you hit your second WFE and found all the links pointed back to your first WFE and no matter what you did you could not fix this.

                    Taken in it’s simplest, most basic explanation what you put in this field, is what all links on MOSS will be prefixed with.  So if you have DocumentA.doc in the Shared Doc lib off of your main site collection. Your URL to it will be http://<Load balanced URL value>/Share documents/DocumentA.doc.

                     So why do we want this? What purpose does it serve? It is all around how NLB works and how to make the most of it. Without this, all links would end up being based on the local server. Any links you shared would jump to the server, not through NLB. In many, if not all you should not even be able to hit the server directly this way. If you could, under the scenario above, if the server you were hitting suddenly became overloaded, you would be stuck there throughout your session. However, since the Load Balanced URL bounces you back to through the NLB URL, this allows you NLB to properly balance the load.

                    There is a lot of info out there to help you out in NLB I have put together a series of links below which hopefully help you out in your search. Happy hunting!

    Link(s):

    -          TechNet Creating a MOSS web application http://technet2.microsoft.com/Office/en-us/library/5ed10d1c-ffdf-4651-b7b6-cac1de6f9ee11033.mspx?mfr=true

    -          Technet MOSS Configure Alternate Access Mapping http://technet2.microsoft.com/Office/en-us/library/be9d31d2-b9cb-4442-bfc6-2adcdbff8fae1033.mspx?mfr=true

    -          What every SharePoint administrator needs to know about Alternate Access Mappings (awesome series) http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx

    -          MOSS Farm, Virtual server and NLB http://www.sharepointblogs.com/aaronrh/archive/2007/04/13/sharepoint-farm-virtual-server-and-network-load-balancing.aspx

    December 07

    FBA (Forms Based Auth) has it's catches

        

    I have set up a few farms now with FBA hooked into various sources from SQL to Novell LDAP. I can absolutely say you need to CAREFULLY evaluate your requirements against your need for FBA. A lot of the docs (especially marketing) make this sound like a trivial, just plug and play issue. It is far from the truth. If you are running on a tight timeline and do not have a lot of time to investigate issues you WILL run into you need to stay with AD auth if it is an option.

                    While I would have some serious questions for the MS architect(s) who put together the FBA piece with MOSS, the purpose here is not to flame MS, but to make sure you are completely aware of the implications of your choice to utilize non-integrated auth. There are many cases where FBA is the only option, and plenty of examples where it has been used successfully on MOSS implementations. Just be aware, if you have bought into the marketing,  thinking FBA is a simple issue, and have serious non-flexible requirements on at least 2 items on this list, well it is very likely you have grossly underestimated the time required to get the implementation done.

    Let’s examine some of the common ones I have run into:

    MY Sites

                    The word I have gotten from some at MS is this is impossible to have with FBA. I have however found a few blogs which helped me get this up and running. It involves setting up MySites and your SSP site to use FBA however. This creates some serious usability issues with your SSP site that you need to work though.  

     

    Search

                    At the current time (MS says this may be fixed in SP1), search will not crawl FBA content. Which means even if  you have your sites set up with a second AD enabled zone to allow search to crawl that content, it will not crawl any portion of the  MySites, since they are exclusively set up under FBA.

     

    Office Integration

                    This is a huge deal for many clients. A lot of the compelling office integration features with MOSS disappear or totally screw up when you keep client integration turned on with FBA. If your company figured they would get MOSS and then invest in upgrading their office suite to 2007 to take advantage of all the cool integration features, then they do NOT want to use FBA. If they do, they might as well not upgrade their office if the MOSS integration was a major part of the upgrade.

    Membership and Role Providers

                    MOSS ships with some Membership and Role Providers, the problem is once you get out of MS built products they are of limited value. As an example a recent implementation I worked on with FBA, involved a Novell eDirectory system. A quick search will find numerous folks using this with the default LDAP provider.  However, when you have a Novell eDirectory system with SSL enabled, that does not permit anonymous connections, well get ready to sling some custom membership and role provider code.  The good part is, it is relatively easy to do (once you figure out what you are doing) and you get a tremendous amount of control over the auth, and role system.  In terms of security though, one thing that makes managers nervous, the membership provider contains a method “ValidateUser” which passes the username and password for all users into the roleprovider, a perfect place for a retarded coder to place some bad logging code. 

                    I could easily fill 5-10 pages on this coding process and all the fun little issues you can run into, if you do run into issues, feel free to post a comment here and I can give you more info.

    Profiles

                    This is one of those little items that can sting a bit. MOSS needs to have unique names for your user accounts. So unlike the imports you run for AD, it will append the name of your role and membership provider to the beginning of your users names “MembershipProviderName:Username”. This can be one of those little things that bugs you sponsors a bit, especially when they see it on the dropdowns on the top right of the screen or when you see it in the user profile screen.

    Profile Import

                    Good chance if you have had to go the route of the custom membership and role provider, that the built in profile Import for MOSS won’t work for you either. If this is the case you will be writing your own. Not too bad of a coding effort but by the time you get to coding this you will find you are pretty deep into your timeframe and still have a mess of things to sort through.

     

                    Like I said, FBA can and does work. It is just, depending on your specific requirements, it is not always the simple tasks it seems at the get go. If you are in that boat, hopefully you get some guidance on where you need to start researching.