I've struggled with this issue for a while, and read many similar posts from those having the same issue. I have found a solution that worked for me and hopefully others.
Essentially, although the Application Manager and other utilities appear to function properly inside a corporate network, the "phone home" services fail to connect, and leave you with an "expired subscription" or various messages similar to "You're not connected to the internet" and so on.
Adobe adamantly states that the software is "Proxy-aware" so there must be other unresolvable issues, and you should kindly ask your IT team to deactivate firewalls, proxies, virus-protection, etc... (yea, right...). You could also request adding exceptions to 6 or so activation servers on a range of ports, which still doesn't work, and take 6 months and 5 levels of management approval.
In reality, "proxy-aware" is only partly accurate, as shown in the graphic below. I monitored PDApp.exe (Adobe Application Manager) with the ProcessExplorer tool (Windows, sysinternals) while doing several network-active tasks to see where the traffic was being routed.
So, PDApp.exe gets correctly routed via my proxy server for installing apps, running updates, and logging in to the app when opening it up.
However, when getting "Subscription Expired" and "Unable to connect to the internet" and clicking "Try Again" or "Licence this Software", the proxy is ignored and the app attempts to connect directly to ims-na1.adobelogin.com, which fails.
The worst part of this was I went through the 5 levels of management approval and so on to get the two servers Adobe states you need access to for Cloud added as exceptions to our firewall(https://activate.adobe.com and https://lm.licenses.adobe.com/, on ports 23, 80 and 443), and still got nowhere, because without ims-na1.adobelogin.com, you can't proceed past the screen above.
Now, for my solution:
I searched for software that would force a program to use a specific proxy. I came across lots, I have to experience with these so I can't vouch for any particular one, but I chose "Proxifier". (They have one that doesn't require an installer for those who don't have local admin rights.) This one is a trial, I'm sure there are free ones as well, just search a bit more.
The proxy server address can be deduced from watching working software traffic in Process Explorer (right click on "Internet Explorer" and got to properties, then TCP/IP, I could see the proxy being addressed under "Remote address", as see in the graphics above). Alternatively just ask your IT team.
I won't get into how to set up the software, read it's help files; what you want is to take any communications from PDApp.exe that are NOT already destined to your proxy server's address and send them to your proxy server's address. (this is important - some communications from PDApp are proxy-aware and redirecting them will cause them to fail)
Hopefully this helps a few people. Despite the issues I love Adobe's software, and am happy I am using it again.
Thanks for taking a read Jeff, and passing along the information.
My company uses an ISA proxy server (HTTP protocol)
Like many such systems, ISA server does not allow SSL tunnels to ports other than 443 and 563 by default (PDApp attempts to use ports 80 and 8080). The reasoning is that SSL tunnels bypass security policy rules and inspection and therefore creates a security risk, which is taken quite seriously (especially with a company this size (37,000+). Check out http://technet.microsoft.com/en-us/library/cc302684.aspx for more detail.
As an addendum to the initial post, it is critical that the IT team allows SSL tunnels to the required ports. I hadn't noticed this originally as the policy was adjusted to allow access to the addresses Adobe originally provided.
I might add a disclaimer that the software mentioned above and similar can also be used to try and circumvent a company's internet security policies, so make sure you can demonstrate that it is being used to force the proxy server rather than avoid it!
Was this ever resolved? We're having the same problem. I've packaged up Photoshop using the CCP tool, I can deploy it fine (although to package it I had to connect the CCP machine to an ADSL connection), but when I launch the app and click the "License this Software" button, I get a "Internet connction required for subscriptions" message. We use a Webmarshal proxy, set in internet explorer.
Nick we actually have improved handling for proxy servers which will be released on June 17th. You will actually be able to enter the proxy information into the Creative Cloud application.
I would also recommend reviewing the Adobe Creative Cloud Service Access Documentation for IT section of http://www.adobe.com/devnet/creativesuite/enterprisedeployment.html.
Hi Jeff. We have subscribed to Creative Cloud for a few users and cannot licence our installations. We get the same errors described by Ian_M and our Corporate proxy guys are seeing the same behaviours that he described when the CS6 Apps try to connect for licencing. Has anything been done by Adobe to resolve this?. The updated CCP tool would help with intial packaging but probably will not resolve the periodic checking by the App to ensure the CC subscriptions are still valid as I suspect the application will still fail to connect.
OK thanks Jeff.
I can't believe Adobe would release an enterprise packager that cannot work in 99% of enterprises?
Is there anything aside from posting here that I can do to speed up the release of the proxy aware version? Your answer was suitably vague such that I assume you're not sure of its release time yourself..?
Nick the software is already proxy aware. If you are using Windows then please place the proxy configuration in the Internet Options control panel. If you are using Mac OS then you will want to enter the proxy information into the Network preference pane.
Steelkiwi have you asked your corporate proxy guys to review the Adobe Creative Cloud Service Access Documentation for IT section of the Creative Suite Enterprise Deployment page as offered in message #4?
I'm afraid the software is NOT proxy aware, or, at least some parts of it are not. You can see this proved in the first post in this thread - the PDApp.exe application tries to connect directly to the internet for certain tasks rather than through the proxy. I have proved the same thing in my environment, except it's trying to access "http://www-da1.adobe.com" directly for me.
Can I open a support ticket or something to get this escalated?
I have to agree with the other guys here. I placed a temporary Proxy "permit all" bypass for a user. I can see browsing through the proxy. However, when it comes to licensing, I can see 184.108.40.206 (220.127.116.11/24 is Adobe address space) on port80 going DIRECT into the Enterprise network rather than using the IE proxy setting. Hope this helps you locate which part of the software is failing to abide by the proxy setting.
Yes. They have reviewed the document and confirmed that there is nothing blocking access to any of the hosts listed. They advised me that if the Adobe Apps were using the proxy correctly then they don't need to make any changes as our current set of Proxy rules allow the required access. They put in a temporary set of rules to permit all for testing and found that traffic to 18.104.22.168 (22.214.171.124/24 is Adobe address space) on port80 was not using IE proxy settings.
Certainly Nick you are more than welcome to contact our support team and open a ticket. You can contact our chat support at http://adobe.ly/yxj0t6. You are certainly welcome to point the support agent to this discussion.
Please ensure that you are entering the proxy information into the Internet Options control panel or Network preference pane depending on your Operating System. This will likely be one of the first steps you are requested to make.
Hi Jeff. Thought I'd update you on this issue. After working with Adobe support for over a month they finally advised me that there is a problem with their software which is preventing Creative Cloud apps connecting to the required Adobe sites through a Proxy server. The apps don't use the proxy. They try and connect directly. This means that a path must be allowed through the Enterprise Firewall. This itself can be a problem as Adobe cannot provide a list of IP addresses for all of the required Adobe servers. Only hosts names. Enterprise firewalls have rules based on IP's not names so this makes setting up the rules difficult. Adobe support advised me that there will be an upgrade to resolve this but did not give a time frame.
Steelkiwi just to confirm your I.T. department has reviewed http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/c reativesuite/pdfs/ServiceAndSiteURL_List.pdf?
It seems an interesting limitation that the firewall can't be configured to work with a DNS sever to resolve the current real world IP address of the server. Could this information be done manually by pinging the appropriate addresses or some other similar method to resolve the IP address?
Something from me - I worked with Adobe support for a while on this issue, there has recently (in the last few weeks) been an update to the adobe software, and it works better now, but not perfectly.
For me, I can now connect fine and use the creative cloud applications through our proxy, but I still cannot use the creative cloud packager. So for packaging, I have to connect the PC to our ADSL line which as no firewall, and it works fine. Once packaged, I can successfully launch the application on our network through our proxy.
A step in the right direction, and enough for us to start actually using CC apps in the business, but still not 100%. better than nothing, though!
Has a permanent solution to this very annoying issue ever been found?
I just checked it , the same way the 1st post in this discussion checked it - and its still the same issue
The registration tries to connect to the internet WITHOUT ever asking the proxy server.
Why is this such a big deal to fix?
Munk to avoid duplication I would recommend that you review the entirety of the discussion. In particular please make sure your I.T. department have reviewed the documentation referenced in message #4. They also will want to ensure that they are entering the information into the appropriate location for the operating system.