Jump to content

Recommended Posts

Posted

Dear All,

 

We're having a bit of a nightmare with sims.net and the March update. Although I'm not convinced the march update has anything to do with it as our problems starting happening about 3 weeks ago.

 

Basically we're getting the Reason 0 when people try to login. At first it was random people, which turned into the whole school. After speaking to capita, they suggested that we do admin work directly on the server as this with use SQL named pipes and should there be a problem, it will not lock the whole database in maintenance mode.

 

We tried this and it seemed to work for a little bit.

 

Roll forward to today. I performed the March 2009 update last night and all worked ok. I logged into a number of machines and the update run fine. We already had some users who still were getting the Reason 0 problem before the update. They still had the problem after the update, along with some new staff. Capita suggested resetting their passwords in system manager. This actually worked. However, those same people are now getting the same problem. Only this time when we try and reset their password, it doesn't seem to make any difference. Still Reason 0.

 

Our sims.net server is running under Virtual Server 2005r2 but here is the spec.

 

Hosting Server: Dell PowerEdge 2950, 2 x Quad Xeon E5320, 16GB Ram, 1TB SAN

 

Virtual Server (for sims.net): Windows 2003r2, 3.7GB Ram

 

One thing I have notice is that SQL doesn't use any more then 1.7GB. Yet I've assigned 3.7GB to the server. Is there a way I can allocate another 1GB of ram to SQL with it making the machine too slow. Surely that's got to help?

 

Still waiting for capita to get back about the reason 0 issues. I know the detaching the database and reattaching will fix it but it's not ideal. Finance are doing their year end at the moment so they won't be too happy.

 

any help greatly received.

 

Len

Posted

No we haven't changed anything. We have a user who cannot log into sims on their PC but if they use someone elses sims.net login, it works ok. Leaves me to believe it's a database issue rather then a PC issue.

 

The person who then tries another PC still cannot login. So people who cannot login, the problems followes them around the site.

Posted

Capita advise for this would be to dettach the database and re attach.

 

Have you checked the event logs on the machines at the time that users try to login and also take a look at the server at the same time.

Posted

We have experienced this same problem only three weeks ago.

 

We have yet to have the March upgrade rolled out to us so that was not a factor for us.

 

The KB article on the Capita site lists 7 possible fixes, none of which were applicable to us.

 

Capita finally said to detach - re-attach the database, by which time our problem had mysteriously disappeared on its own.

 

We still do not know the cause of the problem, which randomly affected both existing and new users, teaching and non-teaching. Resetting their passwords worked in some cases, not in others.

Posted

I figured that was going to be their standard answer. How easy is it to detached and reattach the database. Capita have remote controlled our server before and said they would prefer to do it. I've had a look at the DBAttach. Is there anything I should do before hand. I think Capita moved the database into another folder and allowed it to be copied back? Does that sound right. I would imagine that's why it took so long. Surely just detaching and re attaching would be ok?

 

In terms of my server event log, I'm getting plenty of these

 

Login failed for user 'SIMSRedirectService'. [CLIENT: 10.82.23.2]

 

&

 

Login failed for user 'sims_sheilab'. [CLIENT: 10.82.23.2]

Posted

We've had a few reason 0's recently. Usually fixed by recreating connect.ini as someone else mentioned, but this wasn't making a difference this time.

 

The only thing we found that seemed to be a common issue, was that SIMS stopped working as soon as the schools internet went down. As soon as the internet came back up, so did SIMS.

 

I know what you're thinking, there is absolutely no link and you're right. We first thought that perhaps the DNS settings were wrong, but they all checked out. We could fully ping the SIMS servers from the workstations and vice-versa.

 

Happens to be a very strange and frequent co-incidence of late though. :confused:

Posted

 

I know what you're thinking, there is absolutely no link and you're right. We first thought that perhaps the DNS settings were wrong, but they all checked out. We could fully ping the SIMS servers from the workstations and vice-versa.

 

Happens to be a very strange and frequent co-incidence of late though. :confused:

 

Just a stab in the dark really. How is dns accessed? We once had a similar problem (not SIMS though) when dns was actually being served by the internet router and we had to install dns internally, because if the router died so did all our thin clients. Of course if you are using an external dns server and internet goes down then.....

HTH

Regards

Garry

  • Thanks 1
Posted
We had the same issue with Reason 0 here, seems to point to a general connection error. Connect.ini all fine, seemed to go away on its own here as well. It seemed to appear for us during periods of high network traffic and when the server was under extreme load. It was especially common when we had the antivirus scan scheduled over lunch with people logging onto it around that time it tended to have a hissy fit!
Posted
Just a stab in the dark really. How is dns accessed? We once had a similar problem (not SIMS though) when dns was actually being served by the internet router and we had to install dns internally, because if the router died so did all our thin clients. Of course if you are using an external dns server and internet goes down then.....

HTH

Regards

Garry

 

Admin server which hosts SIMS is also the DNS server. We wondered if the clients might have somehow been going out of the LAN and then back in, but this wasn't the case.

 

It's a strange one that's for sure.

Posted

I fix reason 0's in the following order,

 

-Check services (you'd be surprised)

-Connect.ini's - check local redirects - check the server's one is correct.

-Add time out (don't ask me why but it sometimes works

-Change server name to IP

-Don't redirect the local connect.ini replace it with the server's one

-De-attach/re-attach

-Reinstall - always reluctant to do this but sometimes your left with no choice

 

If it become a consistent problem more related to usernames you could map the Sims usernames via AD?

 

All of the above work it just depends what the scenario is.

  • Thanks 1
Posted

Think we might have found the cause of the problem but don't really know how to fix it.

 

It seems that the when you use Sims System Manager to create users or reset passwords etc that is when the reason 0 problem starts.

 

We were told not to use system manager on a workstation as if there is a timeout, it leaves the SQL database in maintenance mode and you have to detach and re attach it. Capita suggestion was to do it on the server as this uses named pipes and not TCPIP for connection.

 

We did this and initially we thought it seemed to fix the problem. However, it started going wrong again. We're about 95% sure that it's system manager that is causing problems with peoples accounts and not necesssary the account your editing.

 

Can anyone confirm if they are having the same problem. You might find that when you have the problem, it's always after system manager has been used.

 

I've told our person who uses it to do all the changes at the end of the day. Only people who use sims.net so infrequently are likely to forget their passwords. Why upset our power users because we have to reset someone's password during the day. They can wait until the end of the day and if it goes wrong, it doesn't upset too many people.

  • 5 months later...
Posted

Sorry to post on an old thread....

 

But I have this very issue and dettaching and reattaching hasnt helped...

 

We have just been recommended to upgrade our old server to a faster one.

 

Anyone else have other fixes for this issue?

Posted

To cut a long story short, we can fix it by going into SQL Server Management studio express and making sure the Sims_init box is checked.

Need to stop remote connections first and re-enable once you are done.

Posted
Dropping logins would have resolve the problem when detach? Maybe this was where your differences in outcomes were?

 

if you do that, then all sims passwords will be reset wont they?! that's not ideal....more of a last last resort.

Posted
When we had this problem, I phoned the LEA who did the drop/re-attach routine and fixed it. Unfortunately Reason 0 is a nasty one. The LEA told us SIMS chucks that error message out if it can't think of any other reason code causing the problem. It means anything could have happened!
Posted

we are having this at the momment very random user and machines. Our sims server runs from a sas san, its a esx vm 2008 32bit server with 3gb ram 2 processor, i am not sure weather its processor, disk, ram etc.. anyone care to share there ideas i am running out and slt are moaning, last thing to try is to install it to its own physical server

 

mark

Posted

we are getting alot of reason 0 errors on the machines which are running windows vista, the reception machines were replaced with some HP workstations, the run windows vista and they seem to be the only machines in the school getting this problem. we are currently re-building the client images to see if that solves the problem as we think it is something to do with that rather then the server itself.

 

Our setup for reference is:

 

1x SIMSSERVER Front End (Virtual)

1x SQL-SERVER Back End (Physical) - Runs SIMS2005 Instance

 

James.

Posted

I fix reason 0's in the following order,

 

-Check services (you'd be surprised)

-Connect.ini's - check local redirects - check the server's one is correct.

-Add time out (don't ask me why but it sometimes works

-Change server name to IP

-Don't redirect the local connect.ini replace it with the server's one

-De-attach/re-attach

-Reinstall - always reluctant to do this but sometimes your left with no choice

 

All of the above work it just depends what the scenario is.

 

I agree with all of these although not necessarily the order in which to do it, I'm quite a big fan of reinstalling the client components of a workstation early on! - ie Delete the C:\Program Files\SIMS\SIMS .net folder and rerun SIMSApplicationSetup.exe / SIMSManualSetup.exe / SIMSAmparkSetup.exe...

 

Just a stab in the dark really. How is dns accessed? We once had a similar problem (not SIMS though) when dns was actually being served by the internet router and we had to install dns internally, because if the router died so did all our thin clients. Of course if you are using an external dns server and internet goes down then.....

HTH

Regards

Garry

 

On the SIMS going down when the internet goes down thing -

 

Prior to the ??May?? upgrade the way in which .net framework implemented calls from the Client to an SQL Server changed slightly. Subsequently Capita had to make changes to the SIMS .net code as clients would automatically try to go through the proxy server - for those who use external proxy server this problem could be explained away by this change. Basically no access to proxy = no sims.

 

This got sorted very quickly I hasten to add.

 

 

I figured that was going to be their standard answer. How easy is it to detached and reattach the database. Capita have remote controlled our server before and said they would prefer to do it. I've had a look at the DBAttach. Is there anything I should do before hand. I think Capita moved the database into another folder and allowed it to be copied back? Does that sound right. I would imagine that's why it took so long. Surely just detaching and re attaching would be ok?

 

Detaching and reattaching is a reliable routine but you should really move the DB inbetween. So:

 

Backup SIMS DB

Run DBAttach and Detach Database.

Close DBAttach and Stop SQL Server Service.

Cut and paste DB to elsewhere.

Start SQL Server.

Run DBAttach and Attach Database.

Close DBAttach

Restart SQL Server

 

Also no one else has mentioned it here but keeping on top of cleaning out old SIMS Backups helps with general performance seeing that they typically encroach on the Partition the SQL Server is installed on. I suspect there are some fairly big DB's out there.

 

Also See KB87878, from Capita - mostly happens to express installations but note there is a patch if you think you may be affected.

 

http://support.capitaes.co.uk/websupport/RenderXSL.aspx?KB=KB87878.xmlFalse

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...