cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3892
Views
0
Helpful
17
Replies

TMS Tools Error - Setting Not Found

Patrick Sparkman
VIP Alumni
VIP Alumni

In TMS Tools, when selecting the option to update the TMSPE database connection settings, I get the following error:

Settings Not Found

Could not read current settings, the dialog will be populated with default values:

Once the TMSPE connection settings page loads when I select OK on the previous error, and try to update the settings, I get this error:

Error

Unable to write the TMS Provisioning Extension database settings.

Windows 2008 R2

TMS 14.3.1

TMSPE 1.1

Java 7 Update 21

1 Accepted Solution

Accepted Solutions

Hi Patrick,

Sorry, forgot to mention that in my earlier 'word dump'

But this "Cannot read current settings" is a defect that we've fixed in the next major release of TMS, i.e. due out in April. I don't have defect reference for it just yet, but I can get one.

The problem itself is that when you select "Provisioning Extension Database Connection Settings" in TMS Tools, the issue is that TMS Tools does not look at the proper registry locations for 32 or 64-bit Java install meaning it cannot find where Java was installed.

A possible work around to the issue would be to set a proper JAVA_HOME, i.e. environment variables > system variables on the host machine. For example, could be pointing to something that doesn't exist.

The fix in the code is that we obviously now correctly read both the 32 and 64 bit registry locations when we're trying to find where Java is on the host machine.

cheers,

Dale

View solution in original post

17 Replies 17

Wayne DeNardi
VIP Alumni
VIP Alumni

I've seen that happen before on a box that had had its IP address changed after the installation of TMS/TMSPE/etc - Perhaps this is the cause of your issue?

Unfortunately, I don't have a solution as it was only a dev/test box in our environment so we didn't bother looking in to it any further and just trashed/rebuilt it.  But I'd start looking through TMS / SQL settings / etc for settings showing the old IP address (if this indeed is your issue), of try uninstalling/re-installing the TMSPE.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to mark helpful responses and to set your question as answered if appropriate.

Thanks Wayne, the only thing that has changed on the servers since TMSPE was installed has been TMS, updating it when new releases are out, nothing else has changed.  We have two servers with TMS/TMSPE on them, and both servers were showing these errors when trying to update the PE database settings.  I had to uninstalled PE and reinstall it just to make the database changes I needed.

Hi Patrick,

Well, something must of changed...in particular with TMSPE...if your updating the database location on TMSPE. For example, why are you doing this? Have you moved the TMSPE DB to another SQL Server location...which is what I'm presuming? If that's the case, then I believe I know what this is but just want to clarify if this is what your doing ;)

And when you say "two servers"...are these completely seperate TMS/TMSPE servers or is it a redundant setup?

Dale

Sent from Cisco Technical Support iPad App

Two servers ie redundant to each other.

We copied the TMS and TMSPE databases from one SQL 2008 server to an 2008 R2 server.  With the old SQL database still in place, we were simply repointing PE to use the new SQL server.  So on the PE side, nothing would have changed in regards to the database because the database it was pointing to was still online and running, of course until we made the transition then it would be brought offline.

To my knowledge, nothing has changed with the servers, just the occastional TMS update to the newest release.  Java is still the same version as when I first installed TMSPE.  Windows updates of course are being applied, but that is with any other windows server.

Hi Patrick,

Whenever you make a db move like this...whether its TMS or TMSXE...you need to stop all the TMS and TMSPE related services and IIS on the TMS server to ensure nothing is writing to either db...period.

After the services and IIS stopped...and in this case both servers since its a redundant set up...I would then recommend taking a backup of each db. In fact, you could take the db backups to the new SQL Server and restore them on the new SQL Server.

Now where you put them on the new SQL Server is important to...meaning have you put the dbs in a named instance or the default instance on the new SQL Server? Are you using any special ports on the SQL Server or the default ports? Is the SQL Browser Services running on the new SQL Server. If so, no worry about ports then.

In short, and if i understand u correctly, you were trying to do this on the fly and that's not something i would recommend doing when moving the dbs to a new SQL home.

Dale

Sent from Cisco Technical Support iPad App

Dale -

Everything in your post we followed.  We've already made the SQL transitions, so everything is done and working now.  It's just that we got the noted TMS Tools error in my first post.  The only way to get around it was to uninstall TMSPE and reinstall to make the SQL transition.  The TMS SQL transition went without issue.

Thanks

Hi Patrick,

If I'm reading that last post correcly - you've now fixed it (and no longer get the error) by uninstalling and re-installing the TMSPE - is that correct?

Or are you saying that it's working properly, but you stil get the error in the TMS Tools?

I'm asking as I'm now seeing this on my dev TMS 14.3.1 box again (but the SQL databases for TMS and PE are local).

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to mark helpful responses and to set your question as answered if appropriate.

Correct, the only way I could get around the errors were to do an uninstall and reinstall of TMSPE.  The catch is, I still get the error after I did the reinstall, I checked because I was curious, and it was still there.  I'm curious as to why the error appears, just in case we need to change the SQL settings again.

Hi Guys,

As I stated earlier, I believe I know what the issue is here but I've asked some questions your not answering to me For example, and I know everything is working now, but when you moved the tmsng and tmspe dbs to the new SQL location, did you put the dbs in a named instance or default instance on the new SQL Server? Any special SQL port being used for the dbs? Is the SQL Browser service running? I need these kind of details to tell you what I believe is the issue

cheers,

Dale

Hi Dale,

For mine, the SQL installation is on the same box as TMS (default settings were used in the install, apart from the sa password).

When clicking on the "Provisioning Extension Database Connection Settings" in TMS Tools, I get the "Could not read current settings..." error.  Clicking OK, shows the following screen:

Changing any details on that screen (ie, entering the correct sa password instead of leaving it blank) results in the "Unable to write the TMS Provisioning Extension database settings" error.

The SQL Server Browser service is running on this server.

Wayne

--

Please remember to rate responses and to mark your question as answered if appropriate.

Wayne
--
Please remember to mark helpful responses and to set your question as answered if appropriate.

Patrick Sparkman
VIP Alumni
VIP Alumni

Were using a named instance with no port. SQL browser I believe is on, but can't confirm at the moment.

TMS db was moved and setting were changed without issue. Only TMSPE db settings within TMS Tools is affected which is strange.

Sent from Cisco Technical Support iPhone App

Yes, please confirm whether the SQL Server Browser is enabled since this does/will make a difference. For example, when installing the default instance of SQL Server, the SQL Server Browser is disabled, as it isn?t needed. When installing a named instance of SQL Server, the SQL Server Browser is enabled, as it is responsible for binding the connection to the TCP port the named instance uses. Note that named instances of SQL Server use dynamic TCP ports, so running the SQL Server Browser is highly recommended.

In addition to confirming whether that service is enabled or disabled, can you also please send me a screenshot of your TMS Tools (as it looks right now) and also tell me exactly what you entered for the server\instance in the TMS Tools when you were trying to connect to the tmspe db at the new SQL Server location.

Sent from Cisco Technical Support iPad App

Ok, let me try to explain what's going on here when it comes to using the TMS Tool when changing the TMSPE db location, e.g. when moving the db to another SQL Server location. And keep in mind default instance vs. named instance, in particular when it comes to the new SQL Server location. And also keep in mind, this to help you and others get past these challenges albeit much of this is 'cleaned up' in future releases of TMS and TMSPE.

So let's use the example that the customer is moving the tmsng and tmspe dbs off the local instance of SQL Express to an external SQL Server. Now let's assume the instance on the external SQL Server was a default instance. Now the tmsng db can be accessed by just the SQL FQDN or IP address. This is expected when connecting to the default instance. The same field data for the tmspe db setting requires the inclusion of an instance name, even when using the default instance. Since the instance name is in the connection string, then this is where the SQL Browser service comes into the picture...meaning since your including an instance name, then one would conclude the service is required. We also recommend it in any case.

So when the default instance is in play and when using the TMS Tools to change the tmspe db server\instance, the db server\instance field needs to include the default instance name, e.g. sql.domain.local\MSSQLServer. Again, the SQL Server also needs to have the SQL Browser service enabled since the connection to the SQL is using an instance name. The TMS Tool will report an error when testing the connection (this is a bug). The error will look like this:

"The specific connection settings could not be used to connect to the database.
Press 'Ignore' to continue saving, 'Retry' to retry the connect using the
specified connection settings or 'Abort' to abort the changes. Error: A network-related or instance-specific error occurred while establishing
a connection to SQL Server. The server was not found or was not accessible.
Verify that the instance name is correct and that the SQL Server is configured
to allow remote connections. (provider: SQL Network Interfaces, error: 25 -
Connection string is not valid)"

Ignoring the error and letting the settings save will allow the tmspe service to communicate with the SQL Server appropriately. However, if you ignore the error and save the connection without the instance name, the default instance name of "SQLTMS" is automatically added, which will obviously cause a connection failure to the SQL default instance.

Now there could be situations where the  customer security policies do not allow running of the browser service.  Connections to the instance would need to be done through static ports  defined on each instance.

In that case, and when static ports are defined on each instance, then it's not necessary to enter the instance name, just the server and port. However, and when using the TMS Tools, this needs to be entered in the following manner:

servername.test.com:nnnn

nnnn = port number

Also note the use of a colon and not a comma

Again, and when entered in this manner in TMS Tools, the tool will again make the same complaint as above. But again, select "Ignore" and the settings save will allow the tmspe service to communicate with the SQL Server appropriately.

Both the problems concerning not being able to use comma and the thrown error message are being looked into for future releases.

And finally, and after you make the change in TMS Tools, ignore the error message and then restart the TMSPE service, you can verify the changes by looking at the persistence.mssql file to ensure the connection string you desire is correct. The location of the persistence.mssql file can be found under: C:\Program Files\TANDBERG\TMS\TMSProvisioningExtension\app\etc

I really hope the information provided clarifies to the audience here and/or helps out others when facing this challenge. Again, improvements in this area are being done in future releases

rgds,

Dale

Dale,

Just out of curiosity, can you comment on the thought process behind why TMSPE has different connection requirements than TMS for the SQL server?

Thank you,

Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: