tockwell

Once the RD session host role is installed SIMS will only run if the session host is in install mode i.e. ‘change user /install’. As soon as the session host is put in execute mode the problem will occur. Really strange!

I know Capita are unhelpfully not supporting Windows Server 2016 until Summer (which is 6 months away!). However, I have now determined that this problem occurs as soon as you install the RD Session Host role. If you uninstall the role then SIMS works, install the role and the problem occurs again. Not very helpful if you want to run SIMS on an RDS server bust still interesting.

Hello, I have a problem running SIMS on a Windows Server 2016 RDS server. The problem is such that when pulsar.exe is launched it exits after less than a second (it can be viewed to do this in task manager). It displays no UI whatsoever. If I run SIMSLoad.exe then it appears to complete and the same behaviour can be observed with pulsar.exe. The following is reported in the Application Windows event log: Faulting application name: Pulsar.exe, version: 7.172.36.0, time stamp: 0x58106253 Faulting module name: KERNELBASE.dll, version: 10.0.14393.0, time stamp: 0x57898e34 Exception code: 0xe0434352 Fault offset: 0x000d96c2 Faulting process id: 0x18f8 Faulting application start time: 0x01d25c4ad4ce538e Faulting application path: C:\Program Files (x86)\SIMS\sims .net\Pulsar.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: a64dd0f2-ecd8-4419-a27b-748edc9f0114 Faulting package full name: Faulting package-relative application ID: And the following: Fault bucket 108535750328, type 1 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: Pulsar.exe P2: 7.172.36.0 P3: 58106253 P4: KERNELBASE.dll P5: 10.0.14393.0 P6: 57898e34 P7: e0434352 P8: 000d96c2 P9: P10: Attached files: \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER69B6.tmp.WERInternalMetadata.xml These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Pulsar.exe_1ed5558b7c7e52188d30236830afb9d583cb087_8c966f7d_13ad6d11 Analysis symbol: Rechecking for solution: 0 Report Id: 993ae968-2d67-4291-98e7-b147b870064b Report Status: 0 Hashed bucket: 10aab261858e3ca04af202e161492bd9 And the following: Application: Pulsar.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.IO.FileLoadException I have tried the following: Completely removing and reinstalling SIMS Completely removing and reinstalling .Net (Of course Windows Server 2016 uses .Net 4.6 and will not allow any other version of .Net 4 to be installed as it is part of the OS). Without .Net installed running pursar.exe states that .Net is not installed as one would expect. The same behaviour is observed when logged in as a domain administrator. I have confirmed that the RDS server can PING the SIMS server, access files via SMB, and connect to the SIMS server database via ODBC. The connect.ini and sims.ini files are correct (however removing them does not change the observed behaviour as far as pulsar.exe is concerned) I have tried running pulsar from both ‘C:\Program Files (x86)\SIMS\sims .net’ and ‘C:\Program Files\SIMS\sims .net’ I have tried elevating UAC and running as administrator The SIMS server, the RDS server have all been rebooted and DNS cache cleared Has anybody any ideas what I can try next, as I have a lovely new RDS server waiting to be added and SIMS is the only thing preventing it from being put into production.

Brilliant! Shall I PM you my details or wait to be contacted? :-D

Wow, cool, thanks

Thanks for this! You're a star

Hello, My school still uses ProDESKTOP 8.0 and we have a site licence. I'm afraid after a deployment server went up in smoke (quite literally), it would appear that I have no backup of the original media (after the last backup disk makes the click of death), nor can I locate the original disc. I have tried contacting PTC but they have failed to respond to my e-mail. I'm afraid the school is not interested in upgrading to Creo, so I am a bit of a loss in obtaining the media. I don't suppose anybody has a copy of this or know where it can be download. My school is licensed for this version. Thanks

The problem is that it reports that "there are no Capita SIMS Software Updates to be installed". I don't know how well you know the database schema, but is it possible that SOLUS3 thinks that the version of SIMS is still that of the version it had installed before it was rebuilt?

After getting the agent working and communicating correctly, has anybody been able to force SIMS to be installed?

Many thanks for that

I've extended the concept of the VB script a bit more such that I have written a few functions in VB.NET that will obtain the GUID from the database and then install the agent using that GUID. The code is quite dirty as it is there just to demonstrate the concept. You may wish to run as an administrator user, manage the installation using the uninstall record, or run the setup remotely. I'm going to add this code into an application that my build process runs automatically once the computer is built. Code to call: InstallSIMSAgent(True, GetGUIDFromDatabase("COMPUTERNAME")) code to run the setup: Function RunShell(ByVal AppPath, ByVal AppParm, ByVal AppWait) Try Dim proc = Process.Start(AppPath, AppParm) If AppWait = True Then proc.WaitForExit() Return (proc) Catch ex As Exception Return 0 End Try End Function Private Function InstallSIMSAgent(x64, GUID) Dim msi If x64 = True Then MSI = "\SOLUS3AgentInstaller_x64.msi" Else MSI = "\SOLUS3AgentInstaller_x86.msi" End If Dim SimsServer = "SIMSSERVERNAME" Dim SetupSourcePath = "[url="file://\\PATHTO\DeploymentService"]\\PATHTO\DeploymentService[/url]" Dim KeyPath = "[url="file://\\PATHTO\AgentService"]\\PATHTO\AgentService[/url]" Dim CommandLine = "msiexec.exe" Dim CommandArg = "/i " & Chr(34) & SetupSourcePath & msi & Chr(34) & " AGENTSERVICEADDRESS=" & Chr(34) & "net.tcp://localhost:52966" & Chr(34) & " AGENTID=" & Chr(34) & "{" & GUID & "}" & Chr(34) & " DEPLOYMENTSERVERADDRESS=" & Chr(34) & "net.tcp://" & SimsServer & ":52965" & Chr(34) & " RSAKEYPATH=" & Chr(34) & SetupSourcePath & Chr(34) & " /qn" Dim proc = RunShell(CommandLine, CommandArg, True) Return proc End Function Code to connect to and get the GUID from the database Private Function GetGUIDFromDatabase(ComputerName) Try Dim co, cs, rs, SQL Dim sMachineName Dim sGUID Const SIMSDBInstance = "DBSERVER\INSTANCE" Const SIMSDBUser = "DBUSERNAME" Const SIMSDBPasssword = "DBPASSWORD" 'define the connection string, specify database driver cs = "DRIVER={SQL Server};SERVER=" & SIMSDBInstance & ";UID=" & SIMSDBUser & ";PWD=" & SIMSDBPasssword & ";Initial Catalog=solus3_deployment_server;DATABASE=solus3_deployment_server" 'declare the SQL statement that will query the database SQL = "select s.agent_guid, s.machine_name, a.name, a.last_update from solus3.agent_system s, solus3.agent a where s.agent_guid = a.agent_guid and a.name not like ('(Removed)%') and s.machine_name = '" & ComputerName & "'" 'create an instance of the ADO connection and recordset objects co = CreateObject("ADODB.Connection") rs = CreateObject("ADODB.Recordset") 'Open the connection to the database co.Open(cs) 'Open the recordset object executing the SQL statement and return records rs.Open(SQL, co) Dim da As New System.Data.OleDb.OleDbDataAdapter() Dim ds As New DataSet() da.Fill(ds, rs, "Names") sMachineName = ds.Tables(0).Rows(0).Item(1) sGUID = ds.Tables(0).Rows(0).Item(0).ToString co.Close() co = Nothing Return sGUID Catch Return 0 End Try End Function

This appears to be the best way to get the current GUID from the database if you have lots of clients that have been removed and re-added. select s.agent_guid, s.machine_name, a.name, a.last_update from solus3.agent_system s, solus3.agent a where s.agent_guid = a.agent_guid and a.name not like ('(Removed)%');

I'm happy to demonstrate to the programmers why the software is un-usable in a production network.

Excuse me, I didn't say I didn't know how to do that. This is by the bye anyway as connecting to a server remotely is hardly the annoying and relevant step in this process - the focus is the issue of having to remove and re-add computers when they are rebuilt using WDS. Furthermore we don't 'have' to use SIMS, but all our data and training is invested in it, and other systems are integrated into it. So in that respect we are tied into it.

Has anybody else had the misfortune of using SOLUS3 to deploy SIMS to clients? It looks and functions as though it was designed, developed, and tested in a weekend, by a solitary programmer whose experience of Windows networking and good programming practice was obtained by a quick search on Google. Firstly, it has the most counterintuitive UI known to man – in fact, the method of adding clients and deploying software defies logic, and ignores windows design guidelines (for instance not using the standard AD computer selection common dialogue box, and the need to keep prompting for credential). Secondly, it attempts to solve a problem that doesn’t need to exist in the first place; why does a company like Capita feel that it needs to develop a substandard deployment system rather than allowing their application to be deployed via an MSI or using MSSCCM like every other software package developed in the last 10 years (notwithstanding other applications aimed as schools designed by well-meaning but inexperienced programmers). Essentially, all admins need is an MSI or even a setup programme that will run silently (without any user input), that is generated every time SIMS is updated, that could be deployed using the group policy software installation extension, or MSSCCM. The biggest problem with SOLUS3 is the agent deployment. If the server doesn’t think that the agent is the right version, the agent isn’t installed, or the agent doesn’t match that which the server has a record that the server installed (presumably it has some kind of unique ID), then it isn’t possible to install the agent without removing it and reinstalling it. The assumption that the computer be offline because the agent be offline is non sequitur. The easiest way to demonstrate this behaviour is to deploy the agent on a computer install SIMS &c. then rebuild this computer with the same name (this is of course standard practice way in schools and businesses alike, to refresh a computer). As part of the specialize phase of sysprep, the process will reset the computer account in AD and then re-join the computer to the domain using the computer account. This will result in a computer to which SOLUS thinks the agent is deployed, but the agent is not installed. If the agent is reported to be offline, then there is no way to expedite the installation of the client without first completely removing it and re-adding it; there is only a ‘remove computer’ option. This can happen if the computer is rebuilt, but I have recently had a finance computer report to be offline even though it worked last time SIMS and FMS was updated. To overcome these problems, SOLUS would do well to have a method to reinstall the agent should the agent report to be offline, but a computer with that hostname be contactable. If we take MSSCCM as a model, then the agent could auto-install in this case, or the agent be deployable by other means, or at least an option be there to re-install and re-fresh the agent. The most obvious way to overcome this would be to allow for the agent to be installed via an MSI and Group Policy Installation Extension. Is it possible that deploying the agent to new and existing clients could be effected in this manner? The current situation dictates that, in order to get a computer to deploy SIMS, it was required to remove the agent and targets from the list from the server UI, close and re-open the server UI, add the computer again, and then install the agent, which required entering administrative credentials again. I have had instances whereby the SOLUS3 console in Environment > Agents >> Agents reports that the agent status is offline (even though the computer is running and the agent is running). The only option given with the agent selected is ‘Remove Computer’. If I select ‘Remove Computer’ then the computer is removed from the Agents. The only option then presented to me is to add the client again from Environment >> Targets >> Clients. However, if I attempt to do that, then SOLUS3 informs me that the client is already installed. Therefore, I have to log onto the computer in question and then uninstall the client from Add/Remove programs. If I then deploy the client again then it installs SIMS. If you rename a computer, SOLUS3 does not reflect that the computer has been renamed, it simply reports that the computer of the old name is ‘offline’. It should refer to computers using the SID of the computer (which of course will not change) rather than the computer name. In order to resolve the problem the computer must be removed, the client manually uninstalled and then added again as per the other bug. It is of course bad practice to refer to computer objects using names as they can change, the SID is designed as an immutable identifier and would protect against this. In fact, most of the problems faced with SOLUS3 deployment require the client to be removed from the computer and SOLUS3, and added again, but this is far from a straightforward. It seems that Capita expect the following to be carried out every time a computer is rebuilt! • Connect via RDP to the SIMS server • Open the SOLUS deployment UI • Go to SOLUS agents • Select the failed computer • Click on Remove computer • Click on Update environment • Set the channel to SIMS • Click on select Computers, next to Workstations • Click on Add • Navigate to the required OU (after working out which OU it is) • Click on Browse computers • Select the computer in question and click Add • Click Save • Enter the Administrator credentials (edit: I wrote the steps above in relation to an early version, although the current version is slightly better, the rigmarole is still deficient) On computers that deploy SIMS and FMS, the agent will install SIMS first and then report that there is no Capita software to install. The user may then try and open FMS and it be reported of an incompatible data file. Eventually the agent will deploy the new version of FMS, but the interface would benefit by being more intuitive for the user. It stands to reason that the agent report straight away that both pieces of software need to be upgraded – at least it should know that they are pending – the software knows the installed version of FMS on the client and the current version downloaded. There appears to be no way to expedite the installation of SIMS or FMS from the SOLUS 3 deployment UI. If the computer was off when a new version of SIMS &c was deployed, then there is no way of knowing when the new version will be installed – it is frustrating to know that there is a new version available and that the agent is working, but the client does not appear to be installed. Similarly, if the agent reports that another installation is in progress, then there is nothing that can be done from the SOLUS 3 deployment UI. The ‘message’ is displayed under Environment >> Agents >> Agents – there is no specific information deployed for a particular package (products such as MSSCCM display information for both the deployment status of a package and the status of the agent). However, should this be displayed, then there is little one can do. The logical step for one to take is to select the item and then click on the ‘Check status’ button. This results in the message unhelpfully changing to ‘Agent responded to status check’. This leaves one with no indication of what progress is made with the installation of the package. The logical place for expediting and at least determining the status of a package install is ‘Environment >> Agents >> Targets’, however the only information given is the version. The context menu gives the options of ‘copy computer name to clipboard’ and ‘open network path in explorer’ both of which appear to offer no real value. One cannot easily determine if the correct version is deployed and if it hasn’t, then why. It does not seem logical for this information to be displayed under only ‘Environment >> Agents >> Agents’, and only the last ‘message’ displayed with no history. Reading client and server logs to determine an overview of what installs were successful seems unnecessary. Granted, there is the ‘Environment >> Reports’ option, but this appears to be a particularly vague overview with no details (of least that which I can find) of the status of the deployment of the clients, only listing the result as ‘partially successful’. Another problem is that the application cannot cope with different program files paths, and it is required to install a 32-bit program into the x64 program files folder in a mixed environment. This appears to undermine the point of that folder. In fact, SOLUS 3’s only redeeming feature is that it circumvents the pure stupidity of SOLUS 2 such that SOLUS 2 would update using the current user’s credentials, which would give you either the option of manually going to every computer and logon on as an administrator to update the software, or expose various parts of the registry and file system to the user. Before I was an IT administrator for a school, I worked for a software company that produced server/client applications and was responsible for QA and testing. Software this buggy and fundamentally ill-designed would never be acceptable in a real commercial product. Capita is praying on the fact schools are tied into this maladroit concoction of ini files and other dated concepts. …and relax :-D