SUMMARY
Recently it's been taking longer than 5 minutes for InDesign Server to spin up a new instance when executed by Windows system. This issue appears to be user specific. 

SYSTEM
Operating system version: Microsoft Windows Server 2012 R2 Standard
Processors: Intel Xeon CPU E5-2690 v4 @ 2.60GHz x 4
Adobe InDesign CC Server 2017 12.0.0.81

ISSUE:
InDesign server seems to be taking a long time (> 5 minutes) during initialization.

COMMAND:
./InDesignServer.exe -configuration [name] -port [number]

OUTPUT:
Initializing InDesignServer for port 57106: ================================================================================
InDesign CC Server Version 12.0 x64 .
Copyright 1999-2016 Adobe Systems Incorporated and its licensors. 
All rights reserved. See the other legal notices in the ReadMe. ================================================================================
Fri Apr 16 12:54:43 2021 INFO [server] Initializing
Fri Apr 16 12:54:43 2021 INFO [server] Loading the application
Fri Apr 16 12:54:43 2021 INFO [server] Scanning for plug-ins
Fri Apr 16 12:54:43 2021 INFO [server] Registering 114 plug-ins
Fri Apr 16 12:54:43 2021 INFO [server] Completing Object Model
Fri Apr 16 12:54:43 2021 INFO [server] Saving Object Model
Fri Apr 16 12:54:43 2021 INFO [server] Initializing plug-ins
Fri Apr 16 12:54:43 2021 INFO [server] Calling Early Initializers
Fri Apr 16 12:54:43 2021 INFO [server] Starting up Service Registry
Fri Apr 16 12:54:44 2021 INFO [server] Executing startup services
Fri Apr 16 12:54:44 2021 INFO [server] Using configuration indesign-manager-ws-configuration-slot-22 Fri Apr 16 12:54:44 2021 INFO [server] Initializing Application
Fri Apr 16 12:54:44 2021 INFO [server] Completing Initialization
Fri Apr 16 12:54:44 2021 INFO [server] Calling Late Initializers
Fri Apr 16 12:54:45 2021 INFO [server] Image previews are off
Fri Apr 16 12:54:45 2021 INFO [server] Server Running
Fri Apr 16 12:54:45 2021 INFO [javascript] Executing File: C:\Program Files\Adobe\Adobe InDesign CC Server 2017\Scripts\startup scripts\ConnectInstancesToESTK.js
Fri Apr 16 12:54:45 2021 INFO [javascript] Executing File: C:\Program Files\Adobe\Adobe InDesign CC Server 2017\Scripts\converturltohyperlink\startup scripts\ConvertURLToHyperlinkMenuItemLoader.jsx
Fri Apr 16 12:54:45 2021 INFO [javascript] Executing File: C:\Program Files\Adobe\Adobe InDesign CC Server 2017\Scripts\converturltohyperlink\ConvertURLToHyperlinkMenuItem.jsxbin

ANALYSIS:
The application appears to be getting stuck either during or after executing C:\Program Files\Adobe\Adobe InDesign CC Server 2017\Scripts\converturltohyperlink\ConvertURLToHyperlinkMenuItem.jsxbin
This issue is user specific. In this case, the user is the Windows system. When we launch the application as a different user we do not have this problem.

ATTEMPTED SOLUTIONS:
- Restarting the application
- Restarting the server
- Deleted user specific temp files in C:\Users<username>\AppData\Roaming\Adobe\Indesign Server<version><locale>

OTHER
It's worth noting that is problem seems to be very similar to this issue:
https://community.adobe.com/t5/indesign/indesign-server-startup-memory-issues/td-p/11500657

However, we removed the user specific temp files and the application continued to take a long time to initialize.

I wanted to complain about the fact that I cannot open an ID-file created in 2011 using an 2021, just updated program (16.1-version), even though I need to pay for it a lot. I am working as a volunteer for a non profit organisation that operates worldwide. I am translating materials. Our organisation is small so it takes time to do the translations. How dare you change the systems so that I have less than 10 years time to benefit from the files that others in Europe have created. I think this is pathetic and greedy. Now I need to take time to recreate the template for myself that I could have got ready from our central office. This is so stupid and wrong. And by the way, it did not help to save the file as a idml-file and open it again. Why is it that updating programs always causes so much extra work for your customers? So annoying and frustrating.

InDesign Server 2021 Windows Edition (16.x)

We had several indd files that had a Paragraph Style listing a font that was not actually used anywhere in the document (no text in the file was using that font.). In other words, the Style said it used "font a", but there was never ANY text actually using "font a" in the file. "Font A" is a non-system font that was installed on the desktop. If you load the indd file in InDesign Desktop, no errors occur, and Preflight says there are no errors, as expected.
If you remove the file from the desktop, and then open the indd file in InDesign desktop, you still get no errors and no preflight errors, even though the font is defined in the Paragraph style.
If you then use COM to control InDesign Server (windows edition), and tell it to load the indd file. InDesign Server will lock up. No errors are shown on the console or event log, IDS just LOCKS UP..
If you package the indd project and tell it to include document fonts, it will not include the font defined in the Paragraph style unless text using that font is actually in the document.
I don't think InDesign Server should LOCK UP in this circumstance.

We had this happen with some 60+ indd files, and it took a lot of trial & error to determine what actually CAUSED the lockup.

To reproduce:
1) Use InDesign Desktop to create an InDesign document.
2) Define a Paragraph style using a font that is NOT installed on the InDesign Server.
3) Define a text frame using that Paragraph style. Do not actually put ANY text in the frame.
4) Save the InDesign document.
5) Use COM to bind to an instance of InDesign server APPLICATION object (called "app" in this example.
6) Use the APPLICATION instance to open the indd file in OpenCopy mode ((InDesignServer.Document)app.Open(<filename>, InDesignServer.idOpenOptions.idOpenCopy)
InDesign server will never come back. It locks up.

If you edit the indd file and change the Paragraph style to be a font that is actually installed on IDS, then the open returns an instance of the DOCUMENT COM object as expected.

SETUP

• IDS Server 14.0.3.433 running on Windows Server 2019 (build 17763.864)




• Local connection using "sampleclient.exe"




• Two test scripts (attached):
  Slow script: "adobe-ids-win-slow.js" (approx 275 KB in size)
  Fast script: "adobe-ids-win-fast.js" (approx 275 KB in size)

PROBLEM

There are two scripts to compare. They are both of identical size, does nothing but declare a variable and return a string value. However, while execution of one of the scripts take a fraction of a second, the other script typically runs for > 10 seconds before completing.

TESTS AND OBSERVATIONS

1) This takes excessive time to run (typically 13 seconds on my test machine):

   C:\Users\Administrator\Desktop>"c:\Program Files\Adobe\Adobe InDesign CC Server 2019\sampleclient.exe" -host localhost:8190 c:\Users\Administrator\Desktop\adobe-ids-win-slow.js

   Script result (std__string): Done

2) This completes quickly (typically in less than 0.1 seconds):

   C:\Users\Administrator\Desktop>"c:\Program Files\Adobe\Adobe InDesign CC Server 2019\sampleclient.exe" -host localhost:8190 c:\Users\Administrator\Desktop\adobe-ids-win-fast.js

   Script result (std__string): Done

3) Adding the "-server" flag to the slow test will make it run fast, since the script isn't passed via SOAP but instead evaluated directly from local disk. This tells me the parsing of the ExtendScript statements isn't slow in itself so the difference seems to lie in the SOAP request handling.

4) Now a really weird part: removing the very first space (before the comment on line 1) in "adobe-ids-win-slow.js" makes it run almost as fast as the fast script when repeating test 1) above. It turns out that "adobe-ids-win-slow.js" MUST start with a / /-style comment in the very first byte to run fast; adding the space back, or removing the comment completely, makes it evaluate slowly again. I've tried other tokens such as semicolon, //-style comment, curly brackets etc but none had the same effect.

5) In contrast to the change in 4), adding spaces before the comment, or removing the comment entirely, from "adobe-ids-win-fast.js" makes no difference in its evaluation performance.

6) Another strange discrepancy is that even when "adobe-ids-win-slow.js" is modified to run fast using the change described in 4) above, the speed is still slower than the "adobe-ids-win-fast.js" variant. They both declare a string of same length but the data INSIDE the string is different, but while "adobe-ids-win-fast.js" completes in < 0.1 seconds the modified "adobe-ids-win-slow.js" takes closer to a full second.

7) All of the tests above run at good speed (less than a second) when connecting to IDS 14.0.2.324 on macOS (tested with Catalina 10.15.7). The minor difference in speed between the slow and fast scripts seen in 6) is still present though, but is again eliminated if the "-server" option is used.

OTHER COMMENTS

I tried running Microsoft's Windows Performance Analyzer to capture what the slow IDS is doing during the long wait. I found that the overhead is located in calls from AFL (Adobe File Library) to the NT kernel, but without debug symbols I couldn't pinpoint it in more detail. My totally unconfirmed suspicion is that gSOAP/2.7 (as returned in the "Server" HTTP header in IDS connections) is applying some content sniffing to detect encoding, data format or other properties of the inlined script, but why this would only take place on Windows is a mystery, and it's also odd that the initial code comment would short-circuit this and improve performance dramatically.

I've also tried disabling various Windows Security settings (Firewall, Virus & Threat Protection, Exploit Protection etc) in case that was interfering with network I/O but I've not found any improvement in that area.

The slowness is not inherent in "sampleclient.exe" either since the root problem was first observed using our own HTTP client, as was the weird workaround of adding the comment string. I'm just using "sampleclient.exe" here to set up a self-contained test case.