TM1 Forum

Can anybody help me out? I'm a newbie on TM1 rather than starting TM1 server as an application...I'm having a problem starting the TM1 as a service. I attached the error I got when I started the service? Is there any configuration required in TM1? or on the Windows Server?

appleglaze28 wrote:Can anybody help me out? I'm a newbie on TM1 rather than starting TM1 server as an application...I'm having a problem starting the TM1 as a service. I attached the error I got when I started the service? Is there any configuration required in TM1? or on the Windows Server?

I'd check the error logs on the Windows server. You'll probably find an entry in the application log which gives you more information about why it stopped.

(Edit: Right click on "My Computer", select Manage, then Event Viewer, then Application.)

However I can make an educated guess.

Most likely, you have invalid entries in your tm1s.cfg file (or no file at all). When you installed the service (whether through Windows or through the TM1 installation process) you would have had to specify the data directory. This directory is sometimes also specified in the .cfg file. (Can't recall whether it's required or not.) If you've copied the data folder from another installation it's possible that the .cfg file has an obsolete data directory path in which case the application error will be something like "Cannot find data directory". Alternatively you may have an invalid log file path specified. It's possible that you have an invalid port number specified, but usually when that happens the server session just doesn't appear in server explorer even though it does start.

There could be a bunch of reasons, but odds are that the reason is somewhere in the .cfg file.

Have you checked that the user you have selected to run the service has the correct security rights?

Yes, I've checked the security, even the administrator iteself cant make the service run.

With regards to the TM1.cfg. From what I read around its just setting TM1 as a service in the command prompt. I think the data directory isnt the problem since the server is okay when I ran it as an application.

appleglaze28 wrote: With regards to the TM1.cfg. From what I read around its just setting TM1 as a service in the command prompt. I think the data directory isnt the problem since the server is okay when I ran it as an application.

Unwise to assume. If the application shortcut contained the argument which specifies the data directory, that will override the path specified in the .cfg file. You won't know that there's a problem until you try to run it as a service, where it WILL pick up the path from the .cfg file. (He says, speaking from experience.)

In any case, you should definitely be looking at the application log.

I tried rechecking the path in the .cfg file against the log & the shortcut and its still the same. I'm not really sure what the problem is cause even the server admin himself couldnt make it run.

appleglaze28 wrote:I tried rechecking the path in the .cfg file against the log & the shortcut and its still the same. I'm not really sure what the problem is cause even the server admin himself couldnt make it run.

But have you looked at the applicatiion log in Windows?

I'm not sure what the error means.

appleglaze28 wrote:I'm not sure what the error means.

Hmmm, "Data directory not specified", you say?

I think it means that you shouldn't use spaces in your folder names.

Remember how I told you that is was most likely a problem with your data directory specification?

And you know how some people hate to say I told you so?

Not me.

I told you so.

I don't know how you installed the service (that is, whether you did it as a "Custom" server via the installation package or whether you used the tm1sd.exe -install command line). What I do know is that either way you would have had to specify a data directory, whether through a dialog box or a command line argument. However you did it, my guess is that the path wasn't registered correctly and the reason that it didn't register correctly is because you have spaces in your file path.

To fix this, I suggest the following:
- Uninstall the service. You'll find instructions for doing this under the Help topic "Setting Up a Remote TM1 Server to Run as a Windows Service" in the Operations guide.
- Get rid of the spaces in your path names. Just because the O/S lets you do something (or sometimes lets you do something if it feels like it) doesn't mean that you should actually do it. Use of anything other than alphanumeric and underschore characters in system object names (including folders) is a prime example of this. (Yes, I know that Microsoft did it with the "Program Files" folder. Yes, the MS 'droid who came up with that idea should be thunked upside the head daily with a large, frozen salmon.)
- Edit your TM1s.cfg file to change the DatabaseDirectory parameter to the new, no-spaces file path. Do the same with the LoggingDirectory parameter if you use it.
- Reinstall the service using the new path, again using the instructions in the Help topic specified above.

Nice explanation Alan.

User could always go into the Windows Registry Settings to determine where the TM1 Service config file lives.

Must say I'm sometimes shocked that users who are unaware of how to resolve this are left responsible to install TM1 as a service. It's a fairly fundamental part of the installation, and there are plenty of other complex areas throughout an installation where things can potentially go wrong (and often do). Not to mention system optimisation through the config file, connectivity issues, server maintenance/backup, etc.

Or change the cfg file so that path with spaces are in quotes, this should mean that the server starts. This should get round the paths with spaces issue.

I have a feeling the user doesn't know where the config is and pushed through the TM1 install with default settings - means the config file could be sitting under the Custom\PDATA folder. If they haven't installed the sample data then I'd wonder if the config file exists at all....hence the 'data directory not specified....' error message.

Steve Rowe wrote:Or change the cfg file so that path with spaces are in quotes, this should mean that the server starts. This should get round the paths with spaces issue.

Yes, I thought of suggesting that, but IMHO it's not a good practice. Quotes yield their own problems when it comes to path names and what Windows requires to identify them. In addition to which, now having seen the path I think that the .cfg file (if any) may be only part of the problem; another part may be with the service definition itself.

Better to clean it up than work around it, but that's JMHO.

i always avoid spaces in file/folder names wherever possible, its just not worth the hassle. What Alan has said should work fine, the service needs to be told where to find the data directory when you install it, it then goes to find the config file to work all the rest out.

HKLM\System\CurrentControlSet\Services\%servicename% (e.g. "planning sample")
key "ConfigPath" has to point to the cfg dir.
"" should help you when your path has spaces

Registry modifications - Modify at your own Risk!
Caution: Editing your registry may cause your system to fail to start!

Can anyone help me out with something related to this.

I was already able to set up the server as a service however, I encountered a new problem. My security is currently link to the Cognos security rather than using TM1's created user.

Everytime I set a user and a user group from the Cognos portal that isnt any of the admin roles. The security disappears. We already deleted all users and user group and set it all up, the security still disppears. We didnt encounter this during the time TM1 was an application.

Has anyone of you have a Cognos BI and use its security than using TM1's own user and is runnin TM1 as a service.

This is my first time to run TM1 as a service and I'm having problems when it comes to logging in. Since before once I log out I can log in again but now when I log out I need to close Architecture or Perspective (Excel) totally before loggin in again if not I'll encounter a problem.

I never encountered when TM1 was still an appliation server.

I've only seen the cognos front end as a demo but i seem to remember that although they had intentions to fully administrate TM1 via Cognos BI, i don't think they had done it all. Might be worth checking but maybe you need to do stuff like that directly in TM1 for now?

As for not logging you out, that sounds like and issue between the 2 sets of software. if you close perspectives it won't log you out as its resident in Excel, its sounds like a similar thing is happening when you issue the logout command to BI. Probably worth speaking to your Cognos / IBM rep and possibly log a fault with them.

Its just that before when I connected TM1's security through Cognos BI's portal...it was working when TM1 was still a application server. Now that its a service I'm encountering lots of issues like any security I got from Cognos BI, When I log out all the security setting for that name that isnt 1 of the 3 admin roles disappear. So technically if I have 10 users all of them wont be able to view any cube unless they are admins

appleglaze28 wrote:Its just that before when I connected TM1's security through Cognos BI's portal...it was working when TM1 was still a application server. Now that its a service I'm encountering lots of issues like any security I got from Cognos BI, When I log out all the security setting for that name that isnt 1 of the 3 admin roles disappear. So technically if I have 10 users all of them wont be able to view any cube unless they are admins

I can't speak to Cognos BI since I don't use it, but there is one thing to consider; which is what login the services are running under.

When we were running our servers as applications, they were running under an administrator account.

If you look at the list of Services in the Computer Management console dialog in Windows, you'll see "Log On As" as one of the columns.

If you use the tm1sd -install method WITHOUT using the optional -u and -w parameters to pass the user name and password, then the service is likely to be installed to log on as "Local System".

I made that mistake with one server and while the server ran fine normally, I encountered errors when it tried to write ASCIIOutput data to a shared folder on another box.

The reason was that the LocalSystem logon didn't have the same network permissions as the administrator account did.

In other words, make sure that the Log On As column shows the same account name that you were using to run the server as an Application. If it doesn't, you could well have a permissions issue. Uninstall (Remove) the service, and reinstall it including the -u and -w parameters (which are listed in the help file article that I referred to earlier in this thread.) That may solve the problem.

As I said I can't guarantee it since I don't know how BI's security model works, but it's worth taking a look at.