Try schema request as http instead of https - if it works it means there is no SSL cert on the IIS box or cert is there but needs to be attached to the website in IIS (sometimes people bind the cert to the default website but not the particular one for the SData or web service). Also like everything else, Allow External Access needs to be checked in Company Maint. Also, I'm sure you've covered basics but just in case (don't hit me) have you turned on SData in System Config and enabled access in Role Maint and installed the ""SData Adapter.exe"" from the Sage 100 2017 image to the IIS box?
Also I know this from our own Web Services for clients who's IIS box was not same as one running Sage 100. When you installed the SData Adapter, was the Windows user account you specified in the installer a domain account? Essentially this user (context) will be accessing ..\mas90\.. via a UNC and we don't want it to be challenged for user creds and want it to not have Read Only access through the share. Here are some other testing you or client's IT can do:
* Run schema request inside the IIS box (remote into it) as a domain account which is a local administrator (doesn't have to be domain admin).
* Run schema request inside the IIS box (remote into it) as the Windows user uses during SData Adapter installation. If it works from here you prolly have firewall problem. If doesn't, just right there in File Explorer type \\server\share\<path to \mas90> and press Enter and see if you get challenged for user creds. If not, then in ..\mas90 try to create a text file then delete it.
* SData uses BOI (almost all web services do). So run one of your BOI scripts on IIS box while logged into as the Windows user for SData.
Also outside of the Guide that Kevin posted, here is a Sage Summit presentation some seasons ago by Kent Mackall. Follow the ""Quick Setup Instructions.txt"" and the PDF. All other files should go on the root of the website's virtual directory on the IIS box. You could try this all on your own machine too.