Yesterday, I learned why project planning and adequate lead time for implementation is so vital. We were instructed by the higher powers to create an instance of these two apps, have it working and in production in two working days. Necessitated by a multi million pound bid (as they always are) that absolutely has to be started on Monday morning.
Especially galling was the fact that this has been on the order books for more than a month but because the pipeline is just barely scrutinised, and by those with less than a complete technical understanding, it got missed.
Luckily it was a standard client\server model and they had sprung for technical support and so much time was spent talking to the support guys, who to their credit were patient, professional and happy to help. The accompanying documentation looked to have been written with the intent of driving technical delivery teams to distraction, or to give customers no choice but to pay for the technical support function because there were several supposedly insurmountable obstacles that turned out to either be ignored altogether or worked around with a different approach. This it seems is the major competence any technical delivery specialist must have in spades to excel.
We got the thing installed, and were about to start on what we thought was a mod to this app when it became apparent that this was actually another app in its own right, requiring as much if not more work to get it working. Luckily, the database team were accommodating, if not frustrated by the whole unfortunate episode. As it stands, we still require permission to add another app to the host server and deliver the clients to the user groups too. Then there's the documentation to write and the discussion about lessons learned, which will be an interesting read for obvious reasons!
Technical learns from this activity were this command:
netsh http add urlacl url=https://+:8103/ user="Domain\Username
This is what it does:
Namespace reservation assigns the rights for a portion of the HTTP URL namespace to a particular group of users. A reservation gives those users the right to create services that listen on that portion of the namespace. Reservations are URL prefixes, meaning that the reservation covers all sub-paths of the reservation path. Namespace reservations permit two ways to use wildcards. The HTTP Server API documentation describes the order of resolution between namespace claims that involve wildcards.
We're scheduled to complete the second app install on Monday so we'll see what happens when this tale continues.
