Jump to content

Windows Integrated API Documentation - link error


tburke

Recommended Posts

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. 

 

image.thumb.png.d5818625405c95361c2db1577fddd3c9.png

Link to comment
Share on other sites

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?

 

2018-12-13_10-31-39.png

 

2018-12-13_10-33-11.png

 

 

 

Regards,
Support

Link to comment
Share on other sites

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?

 

image.thumb.png.62044534f65aade7d238262d34752977.png

 

Pool looks like this.

 

image.thumb.png.fef91f4e38eeca89c7eef75974053694.png

 

And the applications associated with the PasswordstateApps pool looks like this.

image.thumb.png.1a6f2b7b171d5ae73c8dbfb5bb3d2e5d.png

 

 

Link to comment
Share on other sites

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?

 

winapi.png

 

Regards

Click Studios

Link to comment
Share on other sites

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

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

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.

  1. 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.
     
  2. 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.
     
  3. 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. 
     
  4. 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

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

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

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...