| Issue with one user submitting messages |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through August 10, 2011 ⬆ |
◄ ► |
| Author | Message | |||
| Scott F New member Username: Sfisherfl Post Number: 1 Registered: 06-2011 |
Hello, we recently had a storage event on our NowSMS server which required a checkdisk to fix the broken files, ever since then we have had issues with a particular user account. The messages for this user appear to be received from the foreign SMSC (coming inbound) and then the NowSMS server does nothing with the message. However, messages generated by handsets destined for this SMSC are sent fine (outbound). The 2011.qta file for this particular user has not been updated since the day of the storage event. I backed-up that file which caused NowSMS to create a new 2011.qta file but that file is completely. empty. I then deleted the entire user and then recreated them. The QTA file is still zero bytes. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3299 Registered: 08-2008 |
Hi Scott, I'm trying to understand the configuration to try to suggest a path forward. Toward that end, I am having difficulty understanding what you mean by inbound and outbound. Is this an "SMS User" account or an "SMSC" connection? As you mention the 2011.QTA file, I'm assuming this is an "SMS User" account. So I'm focusing on this part of your message first:
Can you explain how NowSMS is configured to route these messages? If the messages are being received, something must be happening to them. Does the SMSIN-yyyymmdd.LOG show these messages being received? Are they perhaps getting dumped into the SMS-IN directory for 2-way command processing? (If you do not have any 2-way commands, check that directory structure for .IN and/or .SMS files.)
Are you referring to messages being sent out by this user account? (I'm not sure what "generated by handsets destined for this SMSC" means in relation to the user account.) Does the SMSWEB-yyyymmdd.LOG show any record of this user account submitting messages? -- I'm guessing that there is some sort of configuration information, specific to how you want messages to be processed, that is not in place like it was before the disk corruption event. I need to understand the message flow and configuration better in order to make any guesses about that. One thing that does come to mind, however ... and this is a bit of a longshot, but I'll mention it anyway. I do recall a customer that was having issues after a disk problem where Windows was redirecting the NowSMS configuration program so that when NowSMS attempted to update its configuration files, they were written to a different directory. The NowSMS server normally reads SMSGW.INI and related configuration files from the ProgramData\NowSMS directory (when running under Windows 2008/7/Vista, older Windows versions use Program Files\NowSMS). However, in some cases, Windows redirects the configuration program to store configuration files in the Users\useracount\AppData\Local\VirtualStore\ProgramData\NowSMS directory. Check to see if you have such a directory structure. If so delete it, and check configuration settings after deleting it. If this directory comes back, try starting the NowSMS configuration program as an Administrator (right click - run as admin). -- Des NowSMS Support | |||
| Frank Danielson New member Username: Fdanielson Post Number: 17 Registered: 02-2006 |
Hi Des- The messages were coming from an SMS User account so they should show up not in the SMSIN log but the SMSWEB log. They weren't being recorded in the SMSWEB log and we originally thought there were no incoming messages from this user. A packet capture did show the SMPP submit_sm messages from the user and messages outgoing from the NowSMS server to the user account were working fine. We did eventually find the problem. We found that incoming messages from a user account get queued in a subdirectory wtih that user's name under the main Q directory. The subdirectory for the user account in question had been damaged and recovered as a file by the chkdsk operation so the incoming messages could not be queued and NowSMS silently dropped them. Recreating the queue directory fixed the problem. It would have helped a lot if there was some error recorded in the logs that indicated messages were being dropped because they couldn't be queued. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 3306 Registered: 08-2008 |
Hi Frank, I was going to ask for more information. However, I was able to successfully recreate this problem, and will submit a bug report to get it fixed in a future update. -- Des NowSMS Support | |||
