2008R2 works fine for us, do eportal first its the easiest then when thats stable migrate the database
Anyone got instructions on how to migtate Serco Factility & ePortal onto a new server 2008 32Bit server (has they dont support 2008R2) from a server 2003 server
Including the database too
2008R2 works fine for us, do eportal first its the easiest then when thats stable migrate the database
Well that's weird, that say it's not supported!
Doing almost same thing right now.
Setup 2008r2 server/s
Get SQL setup with a Cmis_admin database
Serco engineers default method is to connect to the database using a account named STUD_ADMIN
Create new connection file using the above SQL account
Let admin create the blank table structure
Create a temp data set I use 0000/0001 or something like that.
Install licence key.
Go to your old live system, load up admin, make sure no staff are connected
Create a backup of all datasets
Creates backup of templates
Restore both into new admin system
Now setup eportal
Test, test, test again
When happy time to do final backup and turn off old eportal and database server.
Restore latest backup to new system.
Done (I believe it is supported on r2)
Last edited by gaz350; 8th November 2010 at 10:44 PM.
Hopefully i can clear this up a bit. This is my own post, i'm not on company time, i nor Serco will be held liable for it's contents, etc etc, if you want to check this by all means please visit Serco firstline - Facility Support or give support a call.
But, this is how it is - the current hardware spec says on it that we don't support R2. The reason for this is R2 is only released as a 64bit OS. We don't support 64bit OS. This is because we haven't had a full test on it yet. We do however have a lot of schools using it at their own risk and so far the only issues are with the ISAPi filter used for IIS. We have produced a 64bit version of this (dependant on CPU make) and you will need to make a registry edit, as the default location is the 'Wow64sys32' node of the registry, and the software is looking for the key in the root of HKEY_LOCAL_MACHINE\\SOFTWARE.
These are available from support. We reserve the right as per the hardware spec states to request you rebuild the machine as a 32bit box should we encounter issues we believe are due to the 64bit architecture.
So that's the low down on what we do and don't support and why.
Now for the original question...
What Gaz said is bang on. The only thing to bear in mind which you may or may not already know is to restore templates first. So restore the templates file, then go to Students | Configuration | User Defined Fields. Click 'ok'. Doing this adds the necessary fields to the necessary tables - if you don't when you restore the data, user defined field data will have nowhere to go.
Do the same for Staff, and Applicants.
The thing to bear in mind is unless you're giving the new server the name / ip / an appropriate DNS entry to replace the old server, and you've named the database the same name and setup the authentication in SQL the same, you will need to give the clients a new connection to the database.
Now is a good time for me to mention that all users should have seperate client files. They should not be shared. The 'start in' path of the shortcut the users have should point to the location of this specific users client files folder. A good idea is to keep them in the home drives of the staff. That way, when you do things like this you can sit at the server and copy them out to a user list, or use script, rather than pushing them out to the individual machines. It's fine to hide the folder if you wish.
Facility Admin uses a file history on the file menu to make life easier accessing the CDB. If you wish to remove the old one and add the new one (you'll have to if you've hidden it or they wont be able to see it to open it), then close Admin, go to c:\windows\cmisadmin.ini on the client, and edit in notepad. Look to the bottom of this file and find the most recent file list. Edit as appropriate and save. Reopen Admin.
You can find supporting information for this on First Line, such documents as 'how to create a database in SQL 2005 for use with Facility Admin' (SQL 2008 is an identical process), 'how to connect Facility Admin to a SQL database', and with the release downloads, installation instructions. There are also instructions for IIS 7 (7.5 is the same but the ISAPI and registry is different as i say). I'm sure continuing to post here also will get you lots of help - look out for my mate John, i'm sure he'll be along with a post sooner or later, and also bear in mind on First Line there are also user forums.
Right now, me on my sofa. During the day, Serco Learning.
john (8th November 2010)
Only the SQL can be installed on a 64 bit server at present, so you will need a 32 bit box for Eportal and Facility to live on if you wish to split the roles up. The release notes also have this warning in them:
"Facility Administration and ePortal can be installed on a 64-bit server, but they are not tested on a 64-bit environment therefore unforeseen issues may arise. "
There was talk that V10.2 will have support for R2 and 64-bit but I've not heard anything to say either way about the V10.2
Remember that running an unsupported config if you have issues you do run the risk of support issues, so always best to follow the guidanace.
On the Firstline site they have a guide to setting up SQL for Facility so follow that and you shouldn't go too far wrong.
And whilst i was writing that... John came along. Rock on John. I'd go with John's advice, unless you're wanting to run on a spec not doable on a 32bit server, and you're doing it at your own risk.
Furthermore, i set up Johns servers in terms of Facility and ePortal we ought to be talking some sense between us.
John - we have done some testing in a 64bit environment which is where the speculation of 10.2 came about, but as yet we haven't done a full cycle. This is also true of 10.3 and therefore 10.3 remains the same in the spec. In fact, i think the new spec which i've just signed off is either on the site, or there abouts. There is now change to speak of. We've changed the formatting slightly and added a line about SQL 2008 R2 but otherwise it's the same.
Thanks for the update Michael. Would have gone into those details but was typing on my phone!!
All good fun then, so my 100% 64bit school is going to need 1 32 bit server.
Next your going to say Serco won't support cmis running on hyper-v and what your also suggesting is that facility admin is yet to be supported on win7 64bit aswell? Hope this isn't going to take aslong as support for ie7!!
lol PM sent.
Thanks for pm and noted.
Forgot to say thanks for posting on here always appreciate company employees stepping into the public domain to support people.
Also a nice tip is to open the connection file using the shortcut to reduce the need for staff to then choose file menu > yourlast.cdb
Off the top of my head I think you just \\path\admin.exe "path to cdb file" in the shortcut
Yeh you can do that no bother. It used to cause some issues with syncing to the ini files due to the content of them (the ini files used to store some of the items now stored in the database) but since we changed that many moons ago i've not heard of any problems.
You're right in what you say, but it's safer to wrap both paths, although technically you only need to wrap them if they have a space in i believe, so
Target: "\\servername\foldername\cmisadmin.exe" "z:\clientfiles\admin.cdb"
Another thing worth me saying while i'm on one is that you may of noticed there is now (and has been for some time) an Admin.exe and a cmisadmin.exe file in the installed directory. There's often some confusion as to which to run and what's going on. So the story goes, it always was admin.exe. Some security softwares and network controlling softwares (there are quite a few) won't let anything names admin.exe run without exceptions putting in, and some of them are dead awkward, and it's something else for us to support.
Therefore, we changed the name to cmisadmin.exe. But ofcourse we couldn't get rid of admin.exe as there were all of those many schools that would then need to update their shortcuts. So, admin.exe simply calls cmisadmin.exe. If you run either of the exe's and then look at the process name that's running, you'll see it is actually cmisadmin.exe which is running. So out of habit i always use cmisadmin.exe. But using either is fine (unless you've got that pesky security software).
Intresting, we run factility stright from the server for the staff.
So what the advantage of having there own file in their home drive?
Is this the way serco recommends? (not to run stright from the server)
Sorry i think you've kind of got the wrong end of the stick - the exe should be run from the server. The cdb file (and most importantly the start in path in the shortcut) should be ran by each user not from a shared folder.
This is because the cdb file stores user settings such as the last active dataset, the last location a backup was taken to, amongst others.
In the folder in the startin path, Facility places an ini file. In this ini file other individual user settings such as window sizes, sort preferences, window positions (particularly important if using multiple monitors) etc etc.
If you share these and someone opens the cdb changes the dataset to next year to start timetabling and saves it, you'll potentially have the rest of the staff logging in and working for a few days in next years dataset before someone realises. Absolute disaster when things like that happen and you essentially have to redo the work.
There are lots of little issues like that which can be potentially catestrophic if you share the clientfiles.
The exe file itself however can be run from one location by everyone.
Hope that's cleared it up.
And yes, that is what Serco recommend, and i'm without doubt the biggest advocate of it. But support will tell you exactly the same if you want to check it out (after all this is a forum i could be anyone - but i'm not lol).
I can also say do ensure every user has there own set of client files, some of ours used to share for some reason and we had real random issues!
There are currently 1 users browsing this thread. (0 members and 1 guests)