First NetScaler Gateway packet flow ( Second NetScaler will not come into picture till the apps are enumerated)
1. The user starts his browser and connects (via hostname) to the external IP address of the NetScaler Gateway FQDN of the first hop. The NSG will authenticate and sends it to the StoreFront
2. The StoreFront in the second DMZ receives the request
3. StoreFront will validate the user based on his credentials
4. The StoreFront on the second DMZ sends the credentials to a server on the internal network hosting the XML service.
5. The XML Service authenticates the user and receives a list of published applications the user has access to. This list will be send back to the StoreFront.
6. The StoreFront will generates a page with the “published apps” and sends the page through the NetScaler in first DMZ back to the user
1. The user clicks his application and the request will be forwarded to the StoreFront
2. The SF again contacts the XML service to determine which XenApp server will handle the request. The XML service returns the IP number.
3. The SF then contacts the Secure Ticketing Authority (STA) to switch the IP address for a Session Ticket. The STA saves the IP address and sends a session ticket to the SF. (The XML and STA server don’t have to be the same server)
4. The SF generates an ICA file with the STA session ticket and the FQDN of the NSG in the first DMZ. This ICA file is send back to the user through the NSG in the first DMZ. As you see the application I clicked was Mozilla Firefox and the FQDN is of the first hop
5. The plugin on the machine of the user reads the ICA file and initiates an ICA connection with the session ticket to the first hop NS in the first DMZ.
6. The NS in the first DMZ sends the Session Ticket through the NS in the second DMZ to the STA for validation. As you can notice below that the First NS sent the same ticket to the 10.104.23.83 which is the ip of the second hop NS and notice that the request has the Host header of 10.104.23.149 which is the STA server, Based on this host header the second hop will understand that I need to send the request to this STA server ( since second hop doesn’t have any STA configuration)
7. The STA validates the ticket and sends the IP address of the XenApp server to the NS in the first DMZ.
You can see that packet 36455 is the same decrypted packet send by first NS is received on this NS and this Second NS made a request to the original STA server 10.104.23.149 in the next packet 36456
In the Next packet on the same second hop you can notice that a response is received from the STA server that the Xenapp server is 10.104.23.149 on port 1494. And the same request is forwarded to the first hop NS in the next packet 36461 ( Remember in my lab both the Xenapp server and STA are same and that’s why we are seeing the same ip 10.104.23.149)
8. The NS in the first DMZ establishes an ICA connection to the IP address of the XenApp server, These connection will be sent/Proxied to the Second Hop NS and the first hop NS will not try to make connection to xenapp directly. As we can see the first hop DMZ proxied all ICA connection to the second hop 10.104.23.83 and the second hop NS will forward the ICA traffic to the actual xenapp servers.
In the below trace taken on Second Hop you can notice in Green color that the traffic is coming to this hop 10.104.23.83 and this NS is actually making connection to the actual xenapp server 10.104.23.149 as shown in Pink color
9. The XenApp server sends an acknowledgement back to the Second Hop NS ( acting as proxy) which will be sent to the first ho NS . Then the SSL/TLS handshake between the CAG in the first DMZ and the XenApp client will be completed. The ICA session is established and all traffic will flow
BadRequest: resources.network_setup.app_private_network_subnet: Invalid input for dns_nameservers. Reason: ‘18.104.22.168’ is not a valid nameserver. ‘
22.214.171.124’ is not a valid IP address. Neutron server return request_ids. [‘req-512c7a6a-894d-47b0-879a-41d1841ade31’]
The HOT file contains
label: DNS Name Server
description: The IP address of a DNS nameserver in list format
Colleagues! Tell me how to find a way out of the situation when tasks on the client are running, and the server returns an error on timeout? There is an impression that there is no feedback towards the server. The client does not report a successful job.
<event date=”Jul 03 04:00:28 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.NS.StandardItems.Collection.NSDataSrcBasedResourceCollection.FullUpdatePostDataSrcProcessing” module=”AeXSVC.exe” process=”AeXSvc” pid=”1436″ thread=”317″ tickCount=”511697257″><![CDATA[Updating collection membership for collection ‘e50b60e7-a0a7-4e49-b338-b83896d6bb32’ with 0 members.]]></event>
<event date=”Jul 03 04:00:34 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.TaskManagement.ClientTask.*” module=”AtrsHost.exe” process=”AtrsHost” pid=”1636″ thread=”27″ tickCount=”511703840″><![CDATA[TaskExecutionEngine.ProcessPendingRequestList(): Queueing 1 items.]]></event>
<event date=”Jul 03 04:00:34 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.TaskManagement.ClientTask.*” module=”AtrsHost.exe” process=”AtrsHost” pid=”1636″ thread=”460″ tickCount=”511703840″><![CDATA[Resuming task instance Microsoft Outlook 2010 KB2965295 (7/3/2017 12:56:46 AM)(80fc0fdc-3668-42cc-b4dd-21030cda708b)]]></event>
<event date=”Jul 03 04:00:34 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.TaskManagement.ClientTask.BaseClientTask.CheckIsTaskComplete” module=”AtrsHost.exe” process=”AtrsHost” pid=”1636″ thread=”460″ tickCount=”511703855″><![CDATA[BaseClientTask.CheckIsTaskComplete(): Task “Microsoft Outlook 2010 KB2965295” (7/3/2017 12:56:46 AM) – 0 / 1 child instances done. Timeout at 7/3/2017 12:11:46 PM. Will complete at 7/3/2017 8:26:46 AM if 95% of child instances are complete.]]></event>
<event date=”Jul 03 04:00:34 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.TaskManagement.ServerTasks.ServerTaskExecutionInstance.Sleep” module=”AtrsHost.exe” process=”AtrsHost” pid=”1636″ thread=”804″ tickCount=”511703855″><![CDATA[Task instance Quick Delivery: SERVER01 (7/3/2017 12:56:46 AM) is being put to sleep until 7/3/2017 7:01:34 AM. Instance GUID: 80fc0fdc-3668-42cc-b4dd-21030cda708b]]></event>
<event date=”Jul 03 04:00:38 +00:00″ severity=”4″ hostName=”S58SRS” source=”Altiris.NS.StandardItems.Collection.PolicyChangeCollectionUpdateSchedule.OnSchedule_Impl” module=”AeXSVC.exe” process=”AeXSvc” pid=”1436″ thread=”296″ tickCount=”511707802″><![CDATA[Policy Update Schedule was last run on 7/3/2017 6:55:37 AM]]></event>
If this is happening at only one site, the issue is probably specific to that site (e.g. firewall).
The first thing I would check is whether or not these clients can connect to the Data Domain. There is a utility called ddpconnchk that you can run on the client system to verify connectivity to the DD. KB334991 describes how to use ddpconnchk. Note that while the article talks about the “media server”, you should run this on the system where the Avamar client is installed since the clients connect directly to the DD using DDBoost.
If all the connectivity checks succeed, the issue may be certificate related. For example, clients on the other side of a NAT may be rejecting the connection because the NAT IP addresses are not on the DD certificate’s list of Subject Alternate Names. If that is the case, I’d recommend working with support.
Trying to find a way how to turn a SEP14 Standard Client into a SEP14 Dark Network Client. So far, BCS Support have said so far, that uninstall / reinstall is the only way. Don’t think that this is a very feasible way in server environments.
In case there is really now other way to do so, this should be considered in the next SEP14 versions.
Input / feedback is appreciated.
|Product:||Windows Operating System|
|Message:||Your roaming profile is not available. You are logged on with the locally stored profile. Changes to the profile will not be copied to the server. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator.
DETAIL – %1
Possible reasons that your roaming profile is not available include: a network connectivity problem or incorrect permissions on the profile folders.
To troubleshoot this problem, try the following:
|Component:||Microsoft Exchange ActiveSync|
|Message:||IP-based AUTD failed to initialize because the processing of notifications could not be setup. Error code [0x<number>]. Verify that no other applications are currently bound to UDP port [<number>], or try specifying a different port number.|
This event indicates that more than one application is attempting to use the User Datagram Protocol (UDP) listen port.
To resolve this error, do one or more of the following:
Important This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the “Restore the Registry” Help topic in Regedit.exe or Regedt32.exe.
Before you edit the registry, and for information about how to edit the registry, see Microsoft Knowledge Base article 256986, “Description of the Microsoft Windows Registry” (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).
|Source:||Windows Server Update Services|
|Message:||Some client computers have not contacted the server in the last %1 days. %2 have been detected so far.|
|Clients should check in with the server on a regular basis for updates.|
|Clients Not Reporting
Client computers are not reporting status to the WSUS server.
Possible resolutions include:
Verify client computer and server status.