tburke Posted December 12, 2018 Share Posted December 12, 2018 Looks like the link for the "Windows Integrated API Documentation" on the 8519. I reconfirmed with build 8556 and see it there as well. Quote Server Error in '/' Application. Runtime Error Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated. Link to comment Share on other sites More sharing options...
support Posted December 13, 2018 Share Posted December 13, 2018 Hi Tbourke, Can you open IIS and check to see if your Windows API is configured similar to my screenshot below? It should look like a website icon, not a folder icon. Can you also look under the Application Pools to ensure there is one for the WinAPI and also who is it running under? Is it Network Service or some other account? Regards, Support Link to comment Share on other sites More sharing options...
tburke Posted December 13, 2018 Author Share Posted December 13, 2018 It's not, just plain folder. All of my installations I've done I think have looked like this....except I do have an older build still at version 8.4 (build 8459) and it looks like what you have posted with "WinAPI" set as an and application. I clicked on WinAPI and converted it to an application and set it to the PasswordstateApps pool. That seemed to make it work. I was wondering why the winapi wasn't working in the server we rolled out into production and it worked on my original test setup. Is there anything else I should do or change or is what I did probably fine? Pool looks like this. And the applications associated with the PasswordstateApps pool looks like this. Link to comment Share on other sites More sharing options...
support Posted December 14, 2018 Share Posted December 14, 2018 Hi tburke, With these environments where WinAPI is not configured like this, can you tell us if these are old environments that you've upgraded from version 7? If so, we provided some post upgrade instructions for what's required here, and you can find them in the User Manual under the Help Menu - see screenshot below. If you did not upgrade from Version 7, can you let us know so we can investigate? Regards Click Studios Link to comment Share on other sites More sharing options...
tburke Posted December 17, 2018 Author Share Posted December 17, 2018 All of my installations are fresh installs on a newly spun up VM. I just started using PasswordState at version 8.4 (build 8459) so I haven't done any big updates other than those incremental new builds. I usually spin it up in Chef Test Kitchen using a cookbook I wrote to attempt to automate the setup. I'm grabbing the unattended install bits I was told in another post is being updated at the same time as the normal build. https://www.clickstudios.com.au/downloads/passwordstate_unattended_files.zip https://www.clickstudios.com.au/downloads/passwordstate_unattended_script.zip Link to comment Share on other sites More sharing options...
support Posted December 17, 2018 Share Posted December 17, 2018 Hi tburke, Thanks for reporting this, and it does seem that script is a little old and we need to update it - we weren't even aware customers used this We'll work on getting that fixed, and thanks again for reporting it. Regards Click Studios Link to comment Share on other sites More sharing options...
tburke Posted December 17, 2018 Author Share Posted December 17, 2018 I like to use Chef Test Kitchen to spin these scenarios up quickly to test things out. I brought this up in another post I committed in, but not having a working silent installer makes for a messy pipeline. I made the argument that though the PowerShell script to do the install from a loose set of files in an unmarked zip file works...it's not idempotent. it also comes with a huge disadvantage of ClickStudio making a change, then I have to remodify the script on my side (like to disable installing SQLExpress for example). If the silent installer worked, I could make it idempotent by setting a guard to look to see if that package is already installed. So you have two types of installs now, one via the PowerShell Script and one with the default packager. This makes me have to create a guard based on something else, like if the "PasswordState Service" is installed instead of the package. Also, this current issue. More work on your end managing the two types of installs. I'm almost about to bag my Chef Cookbook for this installation in favor of creating a Docker image but I'd still want to automate that installation easily with the lastest and greatest ClickStudio installer before deploying it into my environments. I think the way I can "Plug-In" the IIS server to an existing DB would make this very viable solution. Also, if you need help justifying working on things like posting a cookbook to https://supermarket.chef.io/ or creating an IIS container using Microsoft's own IIS container with your awesome password state app baked into it...I can tell you these days, if I find a docker-compose file that can spin up an entire solution for me to test stuff out on...I'll probably be picking that solution if all other things are the same feature wise. Let me give you a quick example, because this simplified prototyping and minimized what I had to ask my Ops team for resources (to nothing because I just used my local box to spin up all the containers). https://github.com/jfrog/artifactory-docker-examples/tree/master/docker-compose/artifactory From my container host, I ran two lines and I was interacting with the web app in under two minutes. It's cool stuff. I hope you guys check it out and think about at least packaging the installer differently so I can do this. $ sudo ./prepareHostEnv.sh -t oss -c $ sudo docker-compose -f artifactory-oss.yml up -d Link to comment Share on other sites More sharing options...
support Posted December 17, 2018 Share Posted December 17, 2018 Thanks tburke - we'll need to find some time to look into this. Out of curiosity, can you let us know why you are needing to automate this sort of deployment - are you doing this for yourself, or on behalf of other customers using the Free version? Thanks Click Studios Link to comment Share on other sites More sharing options...
tburke Posted December 18, 2018 Author Share Posted December 18, 2018 I'm a DevOps Engineer, it's what I do. :-P I could possibly see using the free version in a very limited setup, but with only five named users this would be overkill for any setup I can think of. However, within an organization that wants to test features before they install, I use the free version in that respect all the time which enables me to figure out if things are ready for production faster with less effort. Automating the deployment opens up all sort of advantages in our organization. The key here is that I automate it once, it gives me all of this. Repeatable deployment (infrastructure as code, not a document that you can't tell has missing pieces or if it's up to date). This helps eliminate snow-flake servers. Testing. I can spin up a new Windows 2016 VM, install our company standard IIS setup (which is not completely vanilla), run the PasswordState deployment. Try out a feature's settings and make sure it doesn't break our production setup. It's a quick sandbox environment that up and running in a couple minutes from scratch. Every but I've posted to the forum been in the last few weeks...because I've only been using PasswordState for the past month or so. I don't have to worry about the state of my setup...it's exactly the same so I don't have to fight my own self when I make a configuration change, forget about it, and wonder why it doesn't work for the next day or so while I debug it. If I'm not 100% sure, I spend the 3-4 minutes destroying and rebuilding my setup. Sounds like allot of thrashing but working in an unknown state is very costly. Disaster Recovery - I know you guys have an HA module, but I haven't convince my org to pull the trigger on that option. With the same automation, I can recover from just having a DB backup, exported keys, and the emergency password. Now that you guys helped point out that I needed to have that GUID1 in my web.config, with automation, I can have our entire system back up and running pretty quickly and I don't have to read through a bunch of documentation to do it. I've been spending most of this last week restoring our systems just to feel super comfortable with deploying this to our entire company to use. Statefulness - This one is my favorite. I've used the word idempotent which means I should be able to run the same automation over and over and come back with the exact results I expect each time and have my systems in the state they should be in. With Chef (or any or the change/state management systems) you run your automation not one time...but continuously. Maybe an admin fat figured something, maybe you get a disgruntled employee with admin access, maybe a hacker trying to change configuration on your server....etc, etc....if I ran my automation again, it should change those configuration back to what I expect and let me know it had to be changed of course. What would be super cool feature would be a way to apply all of my PasswordState configuration setup without having to go through the UI. If I can set it, I can test it. So if another sysadmin came in and made a change, when my automation ran, it would set it back. All changes should go through a change management process. Change then put into the automation configuration and deployed. You want your production configuration and deployment very controlled if you want to have expected results. Keep in mind, there are other pieces to this automation than just PasswordState. For example, I need to setup JRE8 and I just found out some of our templates are missing the "SQL OLE DB provider and SQL ODBC driver". There is setups around preparing the VM to install PasswordState. Currently the only thing I'm tripping over is the PasswordState installation. Let me give you and example of using Inspec to validate my PasswordState installation. This is a Chef tool, I don't have many tests in it right now, but quick way to determine if my newly spun up box got setup to the point of my services are running. # Three different ways to check to see if Java Runtime is installed control 'Java Runtime 8' do impact 1.0 title 'Validate jre8 installation' desc 'Verifies that the PasswordState server setup has jre8 installed' # Check to see if jre available on the command line # C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe describe command('java -version') do its(:exit_status) { should eq 1 } its('stderr') { should match /java version \"1.8/ } end describe powershell('Get-Package') do its('stdout') { should match /Java 8/ } end describe powershell('choco list -lia') do its('stdout') { should match /jre8/ } end end control 'Passwordstate Server' do impact 1.0 title 'PasswordState Server Setup' desc 'Verifies that the PasswordState setup is correctly installed' describe port(80) do it { should be_listening } end describe port(443) do it { should be_listening } end # describe port(9119), :skip do # it { should be_listening } # end describe service('Passwordstate Service') do it { should be_installed } it { should be_enabled } it { should be_running } end end control 'Passwordstate Gateway Service' do impact 1.0 title 'PasswordState Server Gateway Setup' desc 'Verifies that the PasswordState remote gateway setup up and running' describe port(7273) do it { should be_listening } end describe service('Passwordstate-Gateway') do it { should be_installed } it { should be_enabled } it { should be_running } end end Link to comment Share on other sites More sharing options...
support Posted December 18, 2018 Share Posted December 18, 2018 Thanks for the information - much appreciated. We've just uploaded a new version of the unattended install script, which fixes the WinAPI issue, has support for Windows Server 2019, and also includes the unattended install of the SQL Server 2012 Native Client. Regards Click Studios Link to comment Share on other sites More sharing options...
tburke Posted December 18, 2018 Author Share Posted December 18, 2018 I've merged in your changes. Since I couldn't run the script on an existing production machine to update this I just ran the following from the command line, but still needed to right click and make that WinAPI folder into an app then add it to the new pool that created. I can see the help WinAPI docs now so I'm guessing it works but I'll let you know if it doesn't. I ran the script on a clean box and it looks like the WinAPI gets created correctly and works there so I think we are good. Thanks guys! cd $env:windir\system32\inetsrv # Create Application Pool 3 – PasswordstateWinAPI .\appcmd.exe add apppool /apppool.name:PasswordstateWinAPI /managedRuntimeVersion:v4.0 .\appcmd.exe set config -section:applicationPools "/[name='PasswordstateWinAPI'].processModel.idleTimeout:0.00:00:00" .\appcmd.exe set config -section:applicationPools "/[name='PasswordstateWinAPI'].recycling.periodicRestart.time:0.00:00:00" .\appcmd.exe set AppPool PasswordstateWinAPI "/processModel.identityType:NetworkService" Link to comment Share on other sites More sharing options...
support Posted December 18, 2018 Share Posted December 18, 2018 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.