Which version of VMWare will BODS 3.2 Sp3 support on Win 2008?

[Former Member]

Hi,

Can some one tell me Which version of VMWare will BODS 3.2 Sp3 support on Win 2008?

As part of the upgrade we are trying to test the installation of BODS 3.2 sp3 on a VM Machine.

Thank you in advance.

Regards,

Raghu Rayannagari.

[pradeepkumar_singapuri2 · Accepted solution]

Hi ,

We have Data Services running on VMWare. I would think it is independent of the VMWare version but dependent on the Windows version.

If BODS 3.2 installation is supported on Windows 2008, then you are good to go.

Hope this helps.

Best Regards,

Pradeepkumar

[Former Member · Accepted solution]

Thank you, Pradeep !

I see from the BODS 3.2 PAM the supported Server Products are

 Windows XP SP3 Professional

 Windows Server 2003 SP2 (1) (2)

 Windows Server 2003 R2 SP2(1) (2)

 Windows Server 2008 SP1 (1) (2)

 Windows Server 2008 SP2 (1) (2)

 Windows Server 2008 R2 (1) (2)

(1) Datacenter, Enterprise, Standard, and Web Editions supported

(2) 32-bit and 64-bit O/S editions supported

Than this should be good to go I guess.

Thank you once again for the quick reply.

[Former Member · Accepted solution]

Pradeep, it really helped me. Thank you so much.

Also, I have question on this. How does it impact performance? What should be the robust system configuration for best performance on Windows 2008 with BODS 3.2 SP3 installed on it?

[pradeepkumar_singapuri2 · Accepted solution]

Hi Mona,

How the system will perform depends on how many repositories, developers and jobs running on the system. Our development system is BODS 4.0 SP1 and has 2vCPU / 6GB RAM. We have more than 25 repositories configured and have not run into performance issues. The good thing is that you can add additional servers and distribute the various services when required.

Hope this information helps. Good luck

Best Regards,

Pradeepkumar

[Former Member · Accepted solution]

We're running on VM version 4.5, and have 3.2 SP3 installed (as a single instance with BOE & SQL) on a 2008 with 4 procs and 16GB Ram allocated. Performance is great unless we have a run away DS job or issues like the DST bug (fixed in SP4 I think).  We had over 5 million instances of reports, BODS jobs and about 40 users on average and still were running fine. 

So far, RAM and disk space seem to be the only significant items of consideration.  10-20 GB with 2-4 procs assigned will do fine for most needs (development/QA). 

[Former Member · Accepted solution]

Thank you so much Pradeep. Yes, it helped.

[Former Member · Accepted solution]

Hi Ed

The information which you provided is very helpful but I will need some more help from you now. Since you also have the same environment I am just wondering if you have any document or list of steps you followed for this upgrade. Currently we have BODI 2 and we are upgrading it to 3.2 SP3. We are planning to install BODS first and then import the BODI repository into it. We have server installed and client installed on Windows XP at this time and we are planning to install the uprade on Windows 2008 R2 (server) and client on Windows 7. We will be using the SQL Server 2008 and currently we have 2005.

Since I am doing this upgrade for the first time and I am new to BODS, your help will be greatly appreciated.

Will look forward to hear back from you.

[Former Member · Accepted solution]

Hi Mona,

Our 3.2 install was a clean install, not from an upgrade. However, we are moving to 4.0 right now so I can share those steps and they should be directly relevant.  The only concern will be the upgrade of the repos to 3.2 since I have not done that, but the Repo manager on the server has the upgrade function so I assume it will work the same. 

Your process mentioned is what we are doing.  I assume you are installing a BODS only or will BOE also run on the server (and the SQL)?  We had some difficulties trying to do a distributed server setup on 3.1, so went with the single singer model.  The issues were around the WACS/IIS, so we redid the install using Tomcat. 

Due to the activity on the server, I chose to restore recent backups of each LR that was coming over (to a new DB name).  I then created a new LR on the old server and imported the most recent version of everything coming over from our Central Repo into it.  I then detached this new LR and any other LR coming over (the restored version under a new name), and moved those files over to the new server.  Attach to SQL, then using Repo Manager, I upgraded each LR (unsecure) to the current version. In my tests, I was not able to migrate, upgrade and register the old CR as the new CR, hence the new LR with CR content being created and migrated.  Once they are upgraded, register them in the BODS Manager Console (in 4.0 that's in the CMC now).  Then create the new secure CR, and add all content from the new LR into it.  All working well so far.  This differs from the SAP Prescribed method a little, but I found it less taxing and much simpler. 

Since you are going through this process, have you considered moving to 4.0?  On Windows so far, it has been excellent for us, though I have heard of some issues with Dashboards, and other complaints that have not affected us.  Something to consider, but the advantages in the Universe design options in 4.0 greatly outweigh the negatives in my opinion.  I guess it depends more on your licensing. 

Hope that helps!

[Former Member · Accepted solution]

Hi Ed

Any information you are sharing is helping me. We will do install only for 3.2 and then later on upgrade the repository contents. Could you please share the steps for 3.2?

We are not upgrading BO but just DI. We are planning to use Tomcat only, so I guess our steps should be the same.

Thanks

-MS

[Former Member · Accepted solution]

OK - the 3.2 version (I think 3.1 then SP+Patch for highest level ) is a stand alone install.  Grab the master, install and admin docs from OSS.  They are very straightforward.  With those, follow the install model per your situation (SQL & BODI on same server or BODI alone on server).  I suggest all on same server unless it is for production and/or heavy load expected.  With that, you need your CMC admin account and other account credentials for the install.  I followed the install guide completely for our install.  The migration is another story.