App-V 4.5 management Server Service Shutdown
Has anyone seen this before? As soon as I start the Application Virtualization Management Server Service I get this error and it shuts down. I have about 2 dozen servers connecting and running just fine, its just this new one giving me troubles.
Event ID: 44904 "Did not receive core process start message"
The verbose log shows:
.
.
.
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1645, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed database context to '<DATABASE>'."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 5703."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1647, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x0, State: 01004, Text: [Microsoft][ODBC SQL Server Driver]String data, right truncation"
[2009-03-10 21:09:46.315] <SERVER> 4832 6084 SW_SystemDispatcher::init - - - - 2 44904 "Did not receive core process start message.
.
.
.
Event ID: 44904 "Did not receive core process start message"
The verbose log shows:
.
.
.
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1645, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed database context to '<DATABASE>'."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::MapError - - - - 5 65535 "Got unknown error code: 5703."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x1647, State: 01000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english."
[2009-03-10 21:09:44.860] <SERVER> 1492 3988 SW_SQLDataConnection::HandleError - - - - 5 65535 "Error 0x0, State: 01004, Text: [Microsoft][ODBC SQL Server Driver]String data, right truncation"
[2009-03-10 21:09:46.315] <SERVER> 4832 6084 SW_SystemDispatcher::init - - - - 2 44904 "Did not receive core process start message.
.
.
.
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
anonfoo
15 years ago
A little update. I've narrowed this issue down to most likely be a timeout issue between the VAS server and the SQL server. The two are located in different sites. As a test I restored the database to a local sql server, reinstalled, and everything worked fine. I then switched it back to the original sql server and it didnt work again. The question now is: What are the new keys to up the timeout? There is nothing obvious in the registry. I tried the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Server]->"UNAUTHENTICATED_TIMEOUT_SEC" and bumped it up to 1000 from 10 but that didnt help. I also looked in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppVirtServer] but no luck.
Posted by:
kkaminsk
15 years ago
This will cut down the SQL traffic but not necessarily change the SQL timeout.
A new feature of App-V 4.5 is the ability of the Management Server to cache the application publishing information (paths to .ico and .osd files, FTAs, etc.) for all applications from the SQL Server to its own cache. This was done to reduce the amount of queries against the database for each publishing refresh operation. The application publishing information will grow in size based on the quantity of applications that are published and the number of objects associated with each application. In previous versions of App-V, every publishing refresh request that the server handled required several separate queries to the Data Store to build a list of applications and acquire publishing information for the user. With this new feature, the applications objects (publishing information) stored in the Data Store are queried at the first publishing refresh request and cached on the Management Server for subsequent publishing refreshes. This will cache all of the publishing information for all applications in the Data Store. By default, the Management Server will cache the application publishing information for three minutes, greatly reducing the amount of traffic between a Management Server and SQL Server on separate machines. This value can be adjusted by adding the following registry value: For a 32-Bit Windows Server · HKLM\Software\Microsoft\SoftGrid\4.5\Server\DcCacheTimeout For a 64-Bit Windows Server · HKLM\Software\Wow6432Node\Microsoft\Softgrid\4.5\Server\DcCacheTimeout DcCacheTimeout settings · Type: DWORD · Value: In Seconds (Default 180) with no minimum or maximum Each request that is made for a publishing refresh will still require access to the Data Store to build a list of applications for a specific user, but the application objects for publishing information will already be cached on the server. After acquiring a list of applications for the specific user in the Data Store, the applist.xml file will be built by the Management Server using the publishing information stored on the Management Server cache. In the event that a new application is added within the cache timeout value, the application list for the specific user will have an application in it that does not exist in cache. If this occurs it will trigger a full cache update. Because of this behavior, new applications will be immediately available on the next publishing refresh. This feature will reduce the more costly query of application publishing information to a predictable interval and will not reduce the performance of the publishing refresh process on a Management Server. The only queries that will need to be done from the Management Server to the SQL Server for each publishing refresh will be acquiring the list of applications that a user has been authorized to use and retrieving policy settings.
A new feature of App-V 4.5 is the ability of the Management Server to cache the application publishing information (paths to .ico and .osd files, FTAs, etc.) for all applications from the SQL Server to its own cache. This was done to reduce the amount of queries against the database for each publishing refresh operation. The application publishing information will grow in size based on the quantity of applications that are published and the number of objects associated with each application. In previous versions of App-V, every publishing refresh request that the server handled required several separate queries to the Data Store to build a list of applications and acquire publishing information for the user. With this new feature, the applications objects (publishing information) stored in the Data Store are queried at the first publishing refresh request and cached on the Management Server for subsequent publishing refreshes. This will cache all of the publishing information for all applications in the Data Store. By default, the Management Server will cache the application publishing information for three minutes, greatly reducing the amount of traffic between a Management Server and SQL Server on separate machines. This value can be adjusted by adding the following registry value: For a 32-Bit Windows Server · HKLM\Software\Microsoft\SoftGrid\4.5\Server\DcCacheTimeout For a 64-Bit Windows Server · HKLM\Software\Wow6432Node\Microsoft\Softgrid\4.5\Server\DcCacheTimeout DcCacheTimeout settings · Type: DWORD · Value: In Seconds (Default 180) with no minimum or maximum Each request that is made for a publishing refresh will still require access to the Data Store to build a list of applications for a specific user, but the application objects for publishing information will already be cached on the server. After acquiring a list of applications for the specific user in the Data Store, the applist.xml file will be built by the Management Server using the publishing information stored on the Management Server cache. In the event that a new application is added within the cache timeout value, the application list for the specific user will have an application in it that does not exist in cache. If this occurs it will trigger a full cache update. Because of this behavior, new applications will be immediately available on the next publishing refresh. This feature will reduce the more costly query of application publishing information to a predictable interval and will not reduce the performance of the publishing refresh process on a Management Server. The only queries that will need to be done from the Management Server to the SQL Server for each publishing refresh will be acquiring the list of applications that a user has been authorized to use and retrieving policy settings.
Posted by:
anonfoo
15 years ago
Thanks for the reply. I did find that regkey and gave it a try but no dice. I setup replication between two sql servers and set this vas server to connect to the local sql server. That seems to work and will be sufficient. I just hate to leave this as an open item as we have many international offices and I know they're all going to have the same problem. There has to be a regkey for a timeout. I may just have to pony up the $245 for MS Support :(
Posted by:
kkaminsk
15 years ago
Since they are not using a DSN they don't have to expose the timeout value in the registry. There might be an undocumented key but I am unaware of how you would change the timeout for the Management Server Connection. Keep in mind database replication isn't supported (Softricity did) though I've seen a five site multi-master replication work just fine. *shrug*
Posted by:
anonfoo
15 years ago
New Update...this is really strange.
A little recap:
So now I have my Domestic servers pointing to my domestic SQL Server and everything is working fine. The UK VAS server the service just will not start when it points to the Domestic SQL server. It does however install and create the SQL entries for the user$ and server. So I backed up and restored the database to a UK SQL server (set a script to do it nightly) and pointed the UK VAS server to the UK SQL Server. I did this by changing the registry entry under the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Server\"SQLServerName" key and on the App Virt Management Service\sftmgnt.udl file.
Everything is working now.
However heres the wierd part. I have a dummy app with a data/time stamp so I know when and if the replication occured correctly. When I go into the UK VAS Server MMC I notice it is the Production Dummy app and not the UK dummy app. If I do a select * from applications where name='dummy app' on the UK SQL Server I see the correct UK dummy app. This tells me the MMC is still reading off the Domestic server. I looked at SQL connections and say the UK server was actually connecting to both servers. I modified the dummy app through the MMC on the UK server and the modification showed only on the Domestic server. Further investigation found a server name entry in the DATA_SOURCES table in SQL. i updated that table as well but it didnt seem to impact anything.
So now my questions are:
1. Ideally...is there some hidden registry entry to increate the timeout or has anyone seen the error in the original post above?
2. In Softgrid 4.2 and lower and in 3x to change the sql server you changed the server.conf file and rebooted. In 4.5 that file doesnt exist and is replaced by this reg key. But that doesnt seem to work. Does anyone know what I'm missing to change the SQL server completely? Note if I reinstall and at install time point to the UK sql server it works fine but what if I wanted to move the database for some reason like a server upgrade. I dont want to have to reinstall on a dozen VAS servers.
3. Anyone know what the DATA_SOURCES table is used for?
A little recap:
So now I have my Domestic servers pointing to my domestic SQL Server and everything is working fine. The UK VAS server the service just will not start when it points to the Domestic SQL server. It does however install and create the SQL entries for the user$ and server. So I backed up and restored the database to a UK SQL server (set a script to do it nightly) and pointed the UK VAS server to the UK SQL Server. I did this by changing the registry entry under the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Server\"SQLServerName" key and on the App Virt Management Service\sftmgnt.udl file.
Everything is working now.
However heres the wierd part. I have a dummy app with a data/time stamp so I know when and if the replication occured correctly. When I go into the UK VAS Server MMC I notice it is the Production Dummy app and not the UK dummy app. If I do a select * from applications where name='dummy app' on the UK SQL Server I see the correct UK dummy app. This tells me the MMC is still reading off the Domestic server. I looked at SQL connections and say the UK server was actually connecting to both servers. I modified the dummy app through the MMC on the UK server and the modification showed only on the Domestic server. Further investigation found a server name entry in the DATA_SOURCES table in SQL. i updated that table as well but it didnt seem to impact anything.
So now my questions are:
1. Ideally...is there some hidden registry entry to increate the timeout or has anyone seen the error in the original post above?
2. In Softgrid 4.2 and lower and in 3x to change the sql server you changed the server.conf file and rebooted. In 4.5 that file doesnt exist and is replaced by this reg key. But that doesnt seem to work. Does anyone know what I'm missing to change the SQL server completely? Note if I reinstall and at install time point to the UK sql server it works fine but what if I wanted to move the database for some reason like a server upgrade. I dont want to have to reinstall on a dozen VAS servers.
3. Anyone know what the DATA_SOURCES table is used for?
Posted by:
kkaminsk
15 years ago
This article may help understand the requirements but you can tell it is written for versions before 4.5 so it is mainly correct.
http://support.microsoft.com/kb/932136
With the DATA_SOURCES table you should update it to have the correct information. Also if you are plugging Management Servers into the database where they have not been previously attached you will run into issues. What I do is attach the VAS to the database that is being backed up. Move the SQL database and reconfigure the Management Server using the KB then everything should be ok. Otherwise every time you restore the database the Management Servers will not be in the database and you'll have to reinstall them to put them back into the database.
Hope this helps.
http://support.microsoft.com/kb/932136
With the DATA_SOURCES table you should update it to have the correct information. Also if you are plugging Management Servers into the database where they have not been previously attached you will run into issues. What I do is attach the VAS to the database that is being backed up. Move the SQL database and reconfigure the Management Server using the KB then everything should be ok. Otherwise every time you restore the database the Management Servers will not be in the database and you'll have to reinstall them to put them back into the database.
Hope this helps.
Posted by:
anonfoo
15 years ago
Posted by:
Franz
15 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.