Hello All,
I have a project which has been deployed and working for a few years that is going through some upgrades and now I need help figuring out the setup for Windows mode.
Background:
Project currently deployed as Legacy mode in a Virtual Machine through a jump server.
Needs to reach an AWS S3 bucket using IAM role and bucket region.
Currently must turn off Proxy in VM to reach AWS S3, do the work, then toggle the Proxy back on, to finish the automation. Using Invoke Code activity
Changes made/needed:
Project updated to legacy mode
Proxy toggle with Invoke code not working. Mostly getting “Cannot reach credentials server” issue when making it to the “Amazon Web Services Scope”.
I suspect the “Invoke Code” code needs changing due to the update from Legacy to Windows mode but I am unsure. I’ve tried several different code snippets and web searches but have come up empty so far.
Current invoke code code(Used in Legacy project):
Toggle proxy off: System.Net.WebRequeste.DefaultWebProxy = Nothing
Toggle proxy on: System.Net.WebRequest.DefaultWebProxy = New System.Net.WebProxy(“{proxy URL}”, True)
This is likely happening because Windows projects use modern .NET behavior, and WebRequest.DefaultWebProxy works differently compared to Legacy projects.
The Cannot reach credentials server error usually occurs because the IAM metadata endpoint is still going through the proxy.
Try adding the metadata IP to the proxy bypass list or avoid proxy toggling completely by configuring AWS SDK proxy settings directly.
Thank you for the reply! Using what you said I was able to investigate more and figured out we don’t need to toggle the proxy, we only needed to add the proper IPs to the proxy exclusion list. Previously we tried this but apparently didn’t do the correct ones, which is why we went to toggling in the first place.
We added several suggestions to the exclusion list today, the one that ultimately fixed it was the “metadata IP” I believe you were talking about:
< Metadata Service:169.254.169.254 (essential for IAM instance profile credentials).>.
The screenshot below shows partially what we tried. The highlighted metadata IP is what ultimately fixed it, don’t know if it was a standalone or in combination with the other AWS specific IPs we configured in the list.
