Tuesday, July 14, 2015

IIS Application Initialization Quick Reference


  1.  Need to install application initialization module, if IIS 7.5 it's a separate download or WPI, included in IIS 8
  1. Set startMode to AlwaysRunning on application pool
    1. Open configuration editor in IIS on server root
    2. Select system.applicationHost/applicationPools
    3. Click edit items
    4. Find app pool, select and then change startMode in lower pane to alwaysRunning
    5. Hit Apply This changes C:\Windows\System32\inetsrv\config\applicationHost.config

  1. Set applicationDefault preloadEnabled on site
    1. Open configuration editor in IIS on server root
    2. Select system.applicationHost/sites
    3. Click edit items
    4. Find site and select
    5. Expand applicationDefaults in lower pane
    6. change preloadEnabled to true
    7. Hit Apply This changes C:\Windows\System32\inetsrv\config\applicationHost.config
    8. Note: This only changes the defaults for new apps, you may need to change the existing ones yet. You may not need step 3 if apps already exist…

  1. Set preloadEnabled on site
    1. Open C:\Windows\System32\inetsrv\config\applicationHost.config
    2. Find site you're looking for <site name="www.domain.com" id=…
    3. Add preloadEnabled="true"  to first application element tag
    4. You should see a  <applicationDefaults preloadEnabled="true" /> under the site element if you performed step 3
    5. Restart IIS

  1. Set initalizationPage on site and doAppInitAfterRestart
    1. Open configuration editor in IIS on desired site
    2. Select system.webServer/applicationInitialization
    3. Change from to ApplicationHost.config if you want to create a location element in C:\Windows\System32\inetsrv\config\applicationHost.config, otherwise the change will go in the web.config
    4. Set doAppInitAfterRestart to true
    5. Click edit items
    6. Click add
    7. Enter path for initializationPage ( /folder/page?param=something ), leave hostname blank (I think…)
    8. Click apply


CHANGE IDLE TIME_OUT IN ADVANCED SETTINGS ON APPPOOL TO 0

Monday, July 13, 2015

DPM 2010 Slow when Selecting Roverypoint to Recover

It took almost an hour to select a date and time to recover in DPM 2010. It appeared the this was because of high cpu usage by SQL. The query that seemed to be responsible for this was:

SELECT Path, FileSpec, IsRecursive
    FROM tbl_RM_RecoverableObjectFileSpec
    WHERE RecoverableObjectId = @RecoverableObjectId AND 
          DatasetId = @DatasetId and
          iSgcED = 0

I didn't dig into things too much, but it appeared as though it was running this query for every single recovery point for the item selected and it was doing a clustered index scan for each recovery point. I created the following statistic and covering nonclustered index in the DPM db:

CREATE STATISTICS [_dta_stat_1042102753_9_2_3] ON [dbo].[tbl_RM_RecoverableObjectFileSpec]([IsGCed], [RecoverableObjectId], [DatasetId])

CREATE NONCLUSTERED INDEX [_dta_index_tbl_RM_RecoverableObjectFileSpec_7_1042102753__K2_K3_K9_5_6] ON [dbo].[tbl_RM_RecoverableObjectFileSpec] 
(
[RecoverableObjectId] ASC,
[DatasetId] ASC,
[IsGCed] ASC
)
INCLUDE ( [FileSpec],
[IsRecursive]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

Now the above query changed from a clustered index scan to a index seek and key lookup. The time it took to select a recovery point went from about an hour down to a minute.

Wednesday, January 28, 2015

Email When Scheduled Task Fails

1. Create a new scheduled task
2. On the actions tab, click new
3. Change the action to send an e-mail
4. Enter the to, from, subject, text and smtp server information
 For subject and text enter something along the lines of "A schedule task failed on server so and so"
5. Click OK

6. On the triggers tab click new
7. Change the "Begin the task" drop down to "On an event"
8. Click "Custom" under settings
9. Click "New Event Filter"
10. Click the XML tab
11. Check Edit query manually
12. Enter the following XML for the query:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-TaskScheduler/Operational">
    <Select Path="Microsoft-Windows-TaskScheduler/Operational">*[System[Provider[@Name='Microsoft-Windows-TaskScheduler'] and (EventID=201) ]]
and
*[EventData[Data[@Name='ResultCode'] and (Data='1')]] </Select>
  </Query>
</QueryList>

Now anytime a schedule task completes with a result code of 1, an email will go out letting you know. 1 in our case indicates an error. What ever task you have may return other codes to indicate errors. You could say were data > 0.

Monday, January 12, 2015

IIS and Certificates Random Musings

If you view a cert, windows goes out and downloads the root and puts it in the third-party trusted root certificate authorities store.

If you select a cert in IIS binding, windows goes out and downloads the root and puts it in the third-party trusted root certificate authorities store. It also downloads the intermediate certificates and places them in the intermediate certificate authorities store. (Assuming the cert has a proper AIA configured and accessible.) Thus, IIS will work and serve the intermediate certs even if you didn't explicitly install them into the intermediate cert store. I'm sure this was done to make things simple on admins.

I disabled the gateway and dns so that the windows box could not get out to the internet. Windows did not download the chain when viewing the cert by double clicking and IIS only served the one certificate.  IIS did not download the intermediate certs. (It couldn't.)

You can view the certificates IIS serves with openssl:

openssl s_client -showcerts -connect www.domainname.com:443

Of note, it appears as though the windows crypto APIs cache previous root certs. I viewed a cert while the server had internet access. Windows downloaded the root cert and put it in the third-party trusted root certificate authorities store. I removed the root cert from the third party store, disabled internet connectivity and viewed the same leaf cert again. Without an internet it placed the root cert in the third-party trusted root certificate authorities store again.

While disconnected, I manually installed intermediate certs in intermediate store. IIS did not server them until I touched the bindings of the site in IIS. You need to edit the binding in IIS and just hit ok for the new chain to be served. Just adding intermediate certs into the store will not do it.

It looks like IIS creates the cert chain when the binding is configured and then stores it somewhere for future access. Likely so that path resolution doesn't have to occur over and over. IIS just has to do it once on binding configuration. Restarting IIS/the website had no effect. The binding needed to be modified/re-applied. Restarting the server seems to have updated the certificates served by IIS. IIS's cert chain storage must not be persistent.

I tried placing the intermediate cert in the personal store and IIS did not serve it. I tried placing the intermediate cert in the root store and IIS did server it. So technically intermediate certs could go in the root or intermediate store. I would not put them in the root though as that has other implications.

The big take aways here are:
  1. Windows/IIS will try to make things easy for you as an admin and download/configure cert chains for you
  2. IIS will only update the certificates it send to clients when you update the binding or restart the server


In the future I'd like to test out certs with multiple paths and discover how IIS/path resolution determines path priority. Will one store take precedence? Does it base it solely on whatever window's path selection algorithm is? How will auto downloading play in? I personally think the way IIS serves certificates could use an overhaul. It would be nice to be able to server multiple certificates from IIS. For example, depending on client handshake capabilities, serve either RSA or ECDSA hashed cert for authentication to root CA. Then we could easily transition to ECC certs.