Sharepoint 3 Portal Server versus Stand Alone Sharepoint 3 with SB

Discussion in 'Windows Small Business Server' started by thejamie, Aug 7, 2009.

  1. thejamie

    thejamie Guest

    Is there documentation for setting up Sharepoint 2007 on a server that is not
    the SBS domain controller and linking that server into the SBS 2.0 as a link?
    For example can this happen without upgrading Sharepoint 2.0 into a side by
    side with the Portal Server and still allow Sharepoint 3.0 to run on the
    thejamie, Aug 7, 2009
    1. Advertisements

  2. thejamie

    thejamie Guest

    Perfect, I think. It most likely means that some of the functionality will
    be missing, as in email? Or can that be resolved through an SMTP server on
    the Sharepoint that queues the mail and send it to the DC?
    thejamie, Aug 7, 2009
    1. Advertisements

  3. Hi Jamie -

    What exactly is it that you are trying to accomplish, and what specific
    features are causing you to look at MOSS vs. WSS?


    Chad A. Gross

    Chad A. Gross, Aug 8, 2009
  4. thejamie

    thejamie Guest

    Perhaps wrongly, I think that the .NET web parts are programmed against the
    MOSS rather than the WSS. I'm a bit unclear on which one is needed. I am
    also a bit unclear on what the purpose is of the Sharepoint designer. Was
    that a prefix to MOSS?

    thejamie, Aug 8, 2009
  5. Which .Net web parts are you referring to?

    It's kind of tricky to keep track of the SharePoint products, since MS has
    been changing their names with the last few releases. When SBS 2003 came
    out, SharePoint was on v2 - the free edition being Windows SharePoint
    Services (WSS), and the big-brother server edition being SharePoint Portal
    Server (SPS). The next version of SharePoint (v3) which came out a couple
    years ago still has the two editions - the free edition is still Windows
    SharePoint Services (WSS3), but the big-brother server edition is now
    Microsoft Office SharePoint Server (MOSS).

    Regardless, WSS3 and MOSS are very closely related. MOSS is effectively an
    extension of WSS - adding more features, both in terms of functionality
    (farm-wide searches, self-site creation, etc.) and scalability (load
    balancing, etc.)

    There are some web parts that will only work with MOSS, because they depend
    on some of the advanced features in MOSS (such as Service Providers, etc.).
    However, any web part that doesn't explicitly depend on advanced
    functionality in MOSS should work just fine in a WSS site. And considering
    that WSS is free and MOSS - well, isn't - I would set up a WSS test bed
    environment and see if you can get the web parts you need to work with it.
    If not, then you can look at deploying MOSS.

    Also - just to clarify your question on linking from your companyweb to
    MOSS - obviously you can - but the extent of the link from one to the other
    is going to be no different than if you put a hyperlink on your companyweb
    home page pointing out to As far as SharePoint is concerned, your
    companyweb and your MOSS server are going to be in two separate farms, so
    that will limit what sort of integration you can set up between the two


    Chad A. Gross

    Chad A. Gross, Aug 8, 2009
  6. thejamie

    thejamie Guest

    ,I think the Sharepoint 2007 SP1 is MOSS. If not it won't matter because
    that is what is accessible. It is going on a server that run SQL 2008 -
    dbases there went to a virtual. I'm thinking maybe that needs to be wiped
    first because the 2007 uses SQL 2005. Also don't want WSS on the DC -
    limited memory.

    thejamie, Aug 8, 2009
  7. thejamie

    thejamie Guest

    Another reason to go to a separate server - if the second server eventually
    needs to be linked in as a farm, I don't think it can work because the
    database for the WSS on SBS Sharepoint is the Sharepoint 2. I think the farm
    works on 3 only?

    thejamie, Aug 8, 2009
  8. thejamie

    thejamie Guest

    I think there are also problems encountered with the symmetric key on the
    Sharepoint database because it runs under the Local Account and not under a
    service account. The report server has this glitch (may have been fixed) that

    * If the remote SQL Server instance runs as Local System, you can use
    Windows credentials and any valid domain account to connect to the report
    server database.
    * If the remote SQL Server instance runs as a domain user, you must specify
    that same domain user account for the report server connection.

    After running this down, and I expect the Sharepoint 2 has similar security
    properties, I discovered that the database is not created on a WSS upgrade of
    SBS, instead it relies on the database created for SHRPT 2. I believe that
    there are additional problems in the setup...

    To wit:, there is
    a host of things required on the ISA 2004 server to make this thing run.
    This article indicates to me that it is not easy to configure.


    thejamie, Aug 8, 2009
  9. It sounds like you want to run SharePoint 3 / 2007, be able to connect to a
    remote SQL server, and have a farm installation allowing the option to
    grow/expand the farm in the future if you need to. Is this correct?

    If so - this can all be done with the free Windows SharePoint Services 3.0

    First - as I mentioned before, there is not good way to link different
    SharePoint farms together, especially when they're running different
    versions of SharePoint (e.g. SBS 2003's companyweb running WSS 2.0 and
    another SharePoint farm running WSS 3.0). Second - decide what you want to
    accomplish with adding SharePoint 3.0 / 2007 to your network. Your best bet
    from an on-going administration & user satisfaction standpoint is to stick
    with a single SharePoint farm in your organization. This means if you
    deploy SharePoint 3.0 / 2007, you want to move all of your content from your
    companyweb to the new SharePoint farm and stop using the SBS WSS 2.0

    WSS 3.0 can connect to a SQL 2008 backend as well. Go ahead and install WSS
    3.0 on the member server where you want it. If that server is running
    Windows 2003, you will need to download WSS 3.0 from MS. WSS 3.0 is an
    available feature you can install without downloading for Win2k3 R2 &
    Win2k8. When you are installing WSS 3.0, be sure to use the option for "Web
    front-end server." You do not want to select the Stand Alone server option,
    as this will install the Windows Internal Database and configure SharePoint
    automatically as a stand-alone configuration that can not be expanded to
    include other servers in the farm. Once your Web front-end server install
    of SharePoint finishes, the SharePoint Configuration Wizard launches -
    giving you the option to connect to an existing SharePoint farm, or create a
    new farm. Select to create a new farm, and you will be able to specify
    which SQL server you want to use as the data store for the farm (this can be
    the local server you are installing on, or any other SQL server in your
    network). Once the wizard finishes, you have SharePoint 3.0 (2007) running
    on a member server, utilizing SQL 2008 on the back end, and in a farm
    configuration that allows for adding separate front-end web servers in the
    future as your needs dictate.


    Chad A. Gross

    Chad A. Gross, Aug 8, 2009
  10. thejamie

    thejamie Guest

    much obliged

    thejamie, Aug 8, 2009
  11. thejamie

    thejamie Guest

    It would appear from what I've seen that there may be a glitch in the
    "SharePoint Products and Technologies Configuration Wizard".

    I have been trying to install the MOSS 2007 (as opposed to the WSS 3.0) and
    maybe that in itself is a problem.

    What I am noting is that the file security permissions created on the
    Sharepoint_Config and admin databases (file security, not sql security) is
    not the security that the installer needs to complete the installation.
    (What tweaks were created in that msi?)

    If I install it as the local administrator, I don't have access to the
    domain and get shut down - not sure why this is as there is a sql server
    login for that local administrator.

    If I install as a domain user with service permissions or as the domain
    administrator, the file itself only has local security permissions (the local
    which I have added to the login permissions on SQL 2008 server default

    If you note in the name above above, the MOSS is still thinking that it is
    hooked up to the OFFICESERVERS instance rather than the default instance
    (MSSQLSERVER - should be
    it seems no amount of tinkering will get around this factor.

    If I try to reinstall to an already created MOSS Sharepoint_Config/Admin...
    SharePoint Products and Technologies Configuration Wizard informs the user
    that the tables, views, procedures, and functions need to be removed before
    installing. Removing them gets the information recreated in the same
    database (but with a new ADMIN... table) and because the installer tries to
    create one of the tables, the permissions fail (Step 2 always the "An
    exception of type Microsoft.SharePoint.SPException was thrown. Additional
    exception information: Unable to connect to database. Check database
    connection information and make sure the database server is running." as the
    file security doesn't allow the mdf/ldf to be created on the network - it is
    a local file permission only that is created).

    I have added a rule to ISA 2004 (simple rule) telling the firewall that this
    server is a Sharepoint server - I did so because I am not sure that ISA isn't
    blocking something although nothing in the ISA logs indicates it is trying to
    log into the network... well not 100% true - something is being blocked

    SO I am wondering, is there another approach to installing a stand-alone
    Sharepoint on a stand alone server (in the domain) over SQL 2008? Is it
    essential that the OFFICESERVERS (SQL Express) instance be created? If so,
    is the better way to do this to install the SQL Express, such as detach the
    databases and move them to the Enterprise SQL 2008? (What would happen to
    the SPN's if that were done?)

    At one point, regarding permissions, it was obvious that I could not
    uninstall Sharepoint (the wizard can't run, if the wizard doesn't run, the
    uninstall won't run), and that the only way to overcome this gem of a feature
    is to delete the "12" folder in the "..\Program Files\Common Files\Shared
    Files\Web Services\..." in order to uninstall Sharepoint. (plus run Windows
    Installer Cleanup)

    There is also the issue of granting permissions on the RAID drive for the
    log files. While it is pretty certain I can control most if not all of the
    above, it still eludes me as to how I am to run this picky-yune SharePoint
    Products and Technologies Configuration Wizard.

    Any suggestions appreciated.


    thejamie, Aug 20, 2009
  12. thejamie

    thejamie Guest

    Reading your answer again, I can see it is tricky - it looks like you are
    saying install first to create a web server then install again to link to the
    SQL 2008. As it was only today that I figured out how to uninstall the
    original, perhaps I can try installing just the web server and then upgrading
    to the farm.

    thejamie, Aug 20, 2009
  13. thejamie

    thejamie Guest

    Trick was to install the SP1 iso for MOSS.

    thejamie, Aug 29, 2009
  14. thejamie

    thejamie Guest

    fyi, all worked harmoniously with the sp1 moss 07 install, the ent 08 server
    and the sql 08 with the exception of setting up the indexers which require a
    search database (wss_search_machinename). For this I get an error and the
    jist of it is that I am to delete all the tables in this database and start
    over again.

    Is there an alternative to deleting all the tables? The actually error is
    that the WSS_Search contains a user-defined schema. Databases must be empty
    before then can be used. looks to be the only schema owner in that database
    is myself (the sa, dbo, and creator)

    There is an entry (dec 17 08) indicating it maybe due to the FQDN being used
    in the SQL Server setup. In my case, the default instance is also the name
    of the server being used so changing to another name is not an option without
    creating a second server instance, removing the installation and assigning
    the new installation to the instance. A bit confusing.

    thejamie, Aug 29, 2009
  15. thejamie

    thejamie Guest

    Installation is a bit easier after the domain admin adds you to the
    wss_admin_wpg and wss_restricted_wpg. Not sure if both were necessary but it
    allowed me to configure document conversion load balancer service.
    thejamie, Aug 30, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.