XtremIO: Unable to access the X2 WebGUI because incorrect Customer Domain Name System (DNS) addresses are configured on the XMS(Dell EMC Correctable).

Check and modify if relevant ,XMS configured DNS server(s) IP-addr

Example of XMS DNS server(s) configured IP_Addr:

xmcli (tech)> show-dns-servers

Primary: 10.64.224.1

Secondary: 10.64.224.2

Example of reconfiguring the XMS DNS server(s) IP_Addr

xmcli (tech)> show-dns-servers

Primary: 10.64.224.1

Secondary: 10.64.224.2

xmcli (tech)> modify-dns-servers secondary=””

xmcli (tech)> show-dns-servers

Primary: 10.64.224.1

Secondary: None

Note: You need to have a primary DNS server configured before adding or removing secondary DNS server

xmcli (admin)> show-dns-servers

Primary: none

Secondary: none

xmcli (tech)> modify-dns-servers secondary=”10.64.224.1″

The new secondary DNS server will be: “10.64.224.1”

Are you sure? (Yes/NO):yes

***XMX Completion Code: must_first_specify_primary_dns

Related:

Kerberos via IWA Direct

I need a solution

Hi together,

we use 2 ProxySG VA in a DMZ Environment were explicit DNS Servers ( only for DMZ Servers ) are used.
After a Domain Join the DNS Server replied the SRV Kerberos Entries from the LAN Environment.
The Domain Names of the DMZ and the LAN are the same.
Is it possible to join a Domain with a special RODC Name ??

DNS Answers give us only the Adresses of the DOC System

Regards

Thorsten

0

Related:

SourceOne Email Management – SourceOne Search component fails to install. Web Services server could not be reached.

Regardless of if you use a Domino or an Exchange environment the following can be used to test the issue.

Once SourceOne Web Services component is installed it creates a web site/application named “ExDominoShortcut”. This site is used during the install process for validation that Web Services is present. Validate that the following URL can be reached:

http://<SERVERNAME>/ExDominoShortcut/Notes.aspx?getver=1

Where <SERVERNAME> is the Web Services server where Dell EMC SourceOne Search is to be installed. When this site is opened it should return a page which displays a version number or multiple version numbers, for example:

Version=6.7.0

Version=6.6.1

Although after trying the above and you have no access to the site location (http://<SERVERNAME>/ExDominoShortcut/Notes.aspx?getver=1) . Instead you will receive a Network Error like shown below:

“Network Error (dns_server_failure)

Your request could not be processed because an error occurred contacting the DNS server.

The DNS server may be temporarily unavailable, or there could be a network problem.”

dns_error

The Web Server can be pinged by Server Name.

Additional testing reveals that if the ‘Server Name’ is replaced by ‘localhost’ or ‘ServerName.domain’ you can access the site location /ExDominoShortcut/Notes.aspx?getver=1

The issue is related with DNS name resolution.

Related:

I can not send email to domain protected messagelabs.com

I need a solution

I send messages to domain ford.com, nutricia.com, mazdaeur.com, uta.com etc.

Each domain reply back “Remote Server at cluster8a.eu.messagelabs.com (85.158.139.103) returned ‘550 4.4.7 QUEUE.Expired; message expired'” or ” Remote Server at cluster8a.eu.messagelabs.com (85.158.139.103) returned ‘441 4.4.1 Error encountered while communicating with primary target IP address: “421 4.4.2 Connection dropped due to ConnectionReset.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts. The last endpoint attempted was 85.158.139.103:25’

When I try list MX record for e.g ford.com DNS returns 

cluster4a.us.messagelabs.com    internet address = 216.82.251.230
cluster4.us.messagelabs.com     internet address = 67.219.247.49
cluster4.us.messagelabs.com     internet address = 67.219.246.97
cluster4.us.messagelabs.com     internet address = 67.219.251.49
cluster4.us.messagelabs.com     internet address = 67.219.250.193
cluster4.us.messagelabs.com     internet address = 67.219.250.97
cluster4.us.messagelabs.com     internet address = 67.219.246.193

I have 10 mailserver in one subnet 80.188.242.x  Any address is not on blacklist http://ipremoval.sms.symantec.com/lookup/

If I try to connect via telnet on port 25 to messagelabs.com from subnet 80.188.242.x I get answer “connection abort” or something similar.

SMTPDiag from one of the servers

Searching for Exchange external DNS settings.
Computer name is MFX.
VSI 1 has the following external DNS servers:
There are no external DNS servers configured.

Checking SOA for ford.com.
Checking external DNS servers.
Checking internal DNS servers.
SOA serial number match: Passed.

Checking local domain records.
Checking MX records using TCP: mf.cz.
Checking MX records using UDP: mf.cz.
Both TCP and UDP queries succeeded. Local DNS test passed.

Checking remote domain records.
Checking MX records using TCP: ford.com.
Checking MX records using UDP: ford.com.
Both TCP and UDP queries succeeded. Remote DNS test passed.

Checking MX servers listed for info@ford.com.
Connecting to cluster4.us.messagelabs.com [67.219.251.49] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4.us.messagelabs.com [67.219.250.97] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4.us.messagelabs.com [67.219.250.193] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4.us.messagelabs.com [67.219.247.49] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4.us.messagelabs.com [67.219.246.97] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4.us.messagelabs.com [67.219.246.193] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4.us.messagelabs.com.
Connecting to cluster4a.us.messagelabs.com [216.82.251.230] on port 25.
Error: Expected “250”. Server rejected the recipient address.
Failed to submit mail to cluster4a.us.messagelabs.com.

0

Related:

Error: “CWC Login not working. Please try again” in Zero Touch Deployment

User-added image

Login to SD-WAN using Putty.

In order to check if the ZTD service is installed or not, please look in to the following log file:

/tmp/temp.uXJY13q4wT/work.log

User-added image

There is an error in resolving IP address for host: https://sdwanzt.citrixnetworkapi.net

Upon reviewing DNS server configuration, it was observed that the DNS server was not configured on the NetScaler SD-WAN.

It can be configured from the GUI under the Global settings of the Administration Tab:

User-added image

Internet Connectivity is mandatory for ZTD to work. The reason for the same is because the NetScaler SD-WAN needs to download the Zero Touch service from internet.

Related:

XtremIO: WebGUI forced to localhost.localdomain when using DNS name as URL

Article Number: 487619 Article Version: 5 Article Type: Break Fix



XtremIO Family,XtremIO X1,XtremIO HW Gen1,XtremIO HW Gen2 400GB,XtremIO HW Gen2 400GB Encrypt Capbl,XtremIO HW Gen2 400GB Encrypt Disable,XtremIO HW Gen2 400GB Exp Encrypt Disable,XtremIO HW Gen2 400GB Expandable,XtremIO HW Gen2 800GB Encrypt Capbl

After Deploying XMS unable to access WebGUI because URL is changed from hostname to “localhost.localdomain”. Can only access WebGUI by using IP address.

server name in XMS is not updated to DNS name after performing XMS Deploy

After XMS Deploy

Verify that DNS is forwarding correctly from workstation to XMS

1. Open command prompt on workstation
2. Use ‘nslookup’ to verify DNS name has correct IP address
C: nslookup <DNS name here>

Check and modify server name of XMS

1. Login to XMS with ‘tech’ user
2. use ‘show-server-name’ to view the current hostname setting of XMS
Example:
xmcli (tech)> show-server-name
XMS server reports its name: localhost.localdomain
3. Use the ‘modify-server-name’ to set the server-name.
**IMPORTANT – XMS DNS name is NOT always the same as Cluster name**
xmcli (tech)> modify-server-name server-name=”INSERT_XMS DNS_NAME”
Example:
xmcli (tech)> modify-server-name server-name=”PBXTREMIO”
xmcli (tech)> show-server-name
XMS server reports its name: PBXTREMIO

Verify XtremIO WebGUI is accessible via WebBroswer with DNS name as URL

Fix has been verified.

Related:

VNX: NFS issue due to DNS resolution

Article Number: 483305 Article Version: 3 Article Type: Break Fix



VNX1 Series,VNX2 Series

Loss of access to NFS export when a host is added or removed to the host access list for that export.

All hosts were using either RedHat of CentOS.

When there is a huge list of hosts in the access list for an export, and those hosts are entered using Fully Qualified Domain Name (FQDN) instead of the IP address, it is possible that some DNS resolution timeouts appear, causing loss of access to the export to all the hosts in the list.

This loss of access can has being reported to last between 5-10 minutes in a export list with 167 hosts where there were 3 hosts that had no DNS resolution.

The issue started when customer deleted from DNS configuration some hosts that were retired.

It will be recommended to use a test Filesystem prior to apply this solution to production Filesystem

Check DNS resolution for each host in the export list. This can be achieved using “server_ping” command or more practical using “ping” from the Control Station if the Data Movers and Control Station have the same DNS server configured.

Remove from the export access list the hosts that failed to resolve DNS. Check adding or removing a host to the list, whether the access is lost.

Related:

Dell EMC Unity: DNS settings lost during NDU

Article Number: 488027 Article Version: 7 Article Type: Break Fix



Unity 300,Unity 300F,Unity 400,Unity 400F,Unity 500,Unity 500F,Unity 600,Unity 600F,Unity All Flash,Unity Family,Unity Hybrid,UnityVSA,UnityVSA (Virtual Storage Appliance),UnityVSA Professional Edition,UnityVSA VVols Edition,Unity Hybrid flash

After code upgrade the statically configured DNS settings were removed for the management network, contents of file /etc/resolv.conf become erased. User will not receive email about successful completion of upgrade. All services that require DNS name resolution (NTP, SMTP, etc. etc.) will not work properly until DNS settings are re-entered by hand. Other than that, the user will not be able to connect to Unisphere GUI or UEM CLI using the system domain name.

Please note that the NAS server DNS settings are not affected by this issue.

This is currently impacting upgrades involving the below code revisions

  • 4.0.1.8194551 SP1

Code upgrade to product 4.0.1.8194551 erases DNS settings, if the latter were entered manually (Settings -> Management -> DNS Servers: Manage Domain Name Servers -> Configure DNS server address manually). After upgrade the contents of file /etc/resolv.conf are not restored. It will stop the DNS name resolving and delete the domain name information from the system. In turn, it may affect networking services, including NTP and SMTP, and remove the system domain name from the management connection SSL certificate.


Due to a persistence of settings issue that may occur post upgrade to Unity OE (Operating Environment) 4.0.1.8194551, EMC decided to remove this Unity and UnityVSA release from support.emc.com

A revised OE release is available 4.0.1.8404134 Unity SP1.2

Customers who were planning to upgrade to 4.0.1.8194551 are suggested to wait to upgrade to the upcoming release.

For customers already running 4.0.1.8194551, please review that your DNS server preferences are set correctly under Unisphere > Settings > Management > DNS Server, and update as required.

Please contact EMC support if you have any questions – go to EMC Online Support at: https://Support.EMC.com. After logging in, locate ‘Create a service request’.

4.0.1.8404134 SP1.2 has been released which resolve the issue

    Current workaround is to recreate the DNS settings in the management setup

    GUI:

    1. Navigate to the Settings Menu in the upper right
    2. Click on the Management section then DNS Server
    3. For manually configured DNS click Add and re-add the original DNS servers.
    4. Click “Apply” button at the bottom of the dialog.
    5. Navigate to: System –> Service –>Service Tasks
    6. Select “Restart Management Software”, then press “Execute”
    7. Refresh the browser window. You may need to wait for a few minutes to allow management software to start.
    8. If asked, confirm the security exception for this connection.

    dns_missing

    UEMCLI:

    1. Connect to the system by IP address.
    2. For each DNS address, enter the following command:

    uemcli /net/dns/config set -nameServer <value>

    1. Then restart the management software by the command shown below. Note that it should be executed from the service administrator account:

    uemcli –u service –p <service password> /service/system restart

    1. If the security certificate got changed, accept the new certificate as usual.

    After the last step you should be able to connect to the system by name again.

    Upgrade:

    The latest release of SP1 contains the fix for this issue 4.0.1.84.04134

Related:

OneFS Groupnets

Received several questions from the field recently around groupnets, and thought it would make a interesting blog topic.



The Groupnet, was first introduced in OneFS 8.0 as part of the cluster’s multi-tenant support. Within OneFS networking and SmartConnect, multi-tenancy refers to a cluster’s ability to simultaneously handle more than one set of networking configuration. Multi-Tenant Resolver (MTDNS) refers specifically to hostname resolution against DNS nameservers.



Groupnets sit above existing objects, subnets and address pools, in the object hierarchy. They can contain one or more subnets, and every subnet exists within one (and only one) groupnet.



All newly configured and upgraded clusters start out with one default groupnet named ‘groupnet0’. If multi-tenancy is not required, customers will simply use the pre-existing ‘groupnet0’ and not create any others.



In OneFS 8.0 and beyond, Groupnets are the configuration point for DNS settings, which had previously been global to the cluster. Nameservers and other DNS options are now properties of the groupnet object, and configured there in the CLI isi network groupnets and WebUI. Different groupnets allow portions of the cluster to have separate networking properties for name resolution, etc. The recommendation is to create a groupnet for each different DNS namespace that’s required.



Note that OneFS also has a networking object termed a netgroup, used to manage network access. Groupnets are unrelated to netgroups.



The DNS cache is also multi-tenant-aware, so it maintains separate instances for individual groupnets. Each groupnet may specify whether to enable caching or not: It’s enabled by default, and this is the recommended setting for both performance and reliability.



A number of global cache timeout settings are also available. The CLI for managing them is isi network dnscache, and more detail is available via the isi-network(8) manpage. Note, the isi_cbind command retains the same syntax and usage.



Access Zones and groupnets are tightly coupled, and must be specified at zone creation. Zones may only be associated with address pools and authentication providers that share the same groupnet. For example, the following command creates an access zone with groupnet association:



# isi zone zones create lab1 /ifs/data/lab1 –groupnet groupnet1



Or from the WebUI:



groupnet_1.jpg



In a multi-tenant environment, authentication providers (AD, LDAP, etc) need to know which networking properties they should use, and therefore need to be bound to a groupnet. This happens directly at creation time. A groupnet may be specified via the CLI using the create option –groupnet. Or, if unspecified, the default groupnet0 will be assumed. For example:



# isi auth ads create lab.isilon.com Administrator –groupnet groupnet1

Or via the WebUI:



groupnet_2.jpg



Once created, authentication providers may only be used by access zones within the same groupnet. If a provider is created and associated with the wrong groupnet, it must be deleted and re-created with the correct one.



In general, services or protocols which are both externally facing and access zone-aware are also supported with Groupnets. Administrative and infrastructure services like WebUI, SSH, SyncIQ, and so on are not.



When creating new network tenants, the recommended process is:



  1. Groupnet, create and specify nameservers
  2. Access zone, create and associate with groupnet (which must already be created)
  3. Subnet, create within groupnet (which must already be created)
  4. Address pool, create within subnet (which must already be created) and associate with access zone (which must already be created)
  5. Authentication provider, create and associate with groupnet (which must already be created)
  6. Access zone, modify to add authentication provider



Attempting to do things out of this order may create other challenges. For example, if an access zone has not already been created in a groupnet, you will be unable to add an address pool, since it requires an access zone to already be present.



Some customers have a set of host information they want available without DNS and instead wish to specify locally on the cluster. A file /etc/local/hosts can be created for specifying network hosts manually, and, by default, any entries it contains will be used in groupnet0. However, additional groupnets can also be listed in square brackets.



The lines that follow each will be used to populate a hosts file specific to that groupnet. For example:



# cat /etc/local/hosts

  1. 1.2.3.4 hosta.foo.com # default groupnet0
  2. 1.2.3.5 hostb.foo.com # default groupnet0

[groupnet1]

  1. 5.6.7.8 hostc.bar.com # groupnet1
  2. 5.6.7.9 hostd.bar.com # groupnet1



Please be aware of the following considerations:



  • Despite using different nameservers, the address space is still assumed to be unique. OneFS does not permit IP address conflicts even if the conflicting addresses are in different groupnets.
  • Names of authentication providers also must be unique, even across groupnets. You cannot, for example, have two AD providers joined to the same domain name even if they are in different groupnets (and therefore the same name may resolve to different addresses and machines.)
  • It is permissable to have a configuration wherein some nodes are unable to route to nameservers of some groupnets, although that practice is not recommended for the default groupnet. In this case all tasks associated with these limited groupnets, including CLI and WebUI administration, must be performed on nodes that are capable of these lookups.



So, the SmartConnect hierarchy encompasses the following network objects:



  • Groupnet: Represents a ‘network tenant and can contain a collection of subnets’. It also contains information about DNS resolution of external authentication providers.
  • Subnet: Contains a netmask and an IP base address, together which define a range of IP addresses. A subnet can be either IPv4 or IPv6. A subnet contains a collection of IP pools.
  • IP Pool: An IP Pool is an object that contains a set of IP addresses within a subnet and configuration on how they are used. An IP Pool can be associated with a set of DNS host names. An IP pool may be either static or dynamic, based on the –alloc-method setting on the IP Pool. This attribute indicates whether the IPs in the pool can move back and forth between nodes when a node goes down.
  • Network Rule: A network rule contains specifications on how to auto-populate a pool with interfaces. For example, a rule could specify that the pool contains the ext-1 interface on all nodes. If a pool contains more than one network rule, they are considered additive.



Network objects are specified by their network ID, which is a series of network name identifiers separated by either periods or colons.



To create a SmartConnect groupnet and configure DNS client settings, run the isi network groupnet create command. For example, the following command creates a groupnet and adds a DNS server with caching enabled:



# isi network groupnet create groupnet1 –dns-servers=192.168.10.10 –dns-cache-enabled=true



Or via the WebUI:

groupnet_3.jpg

Unless it’s the default, a groupnet can be fairly easily removed from SmartConnect. However, if a groupnet is associated with an access zone, removing it may adversely impact other areas of the cluster config. The recommended order for removing a groupnet is:



  1. Delete IP address pools in subnets associated with the groupnet.
  2. Delete subnets associated with the groupnet.
  3. Delete authentication providers associated with the groupnet.
  4. Delete access zones associated with the groupnet.



To delete a groupnet, run:



# isi network groupnet delete <groupnet_name>



Note that in several cases, the association between a groupnet and another OneFS component, such as access zones or authentication providers, is absolute and can’t be modified to associate it with another groupnet. For example, the following command unsuccessfully attempts to delete groupnet1 which is still associated with an access zone:



# isi network modify groupnet groupnet1

Groupnet groupnet1 is not deleted; groupnet can’t be deleted while pointed at by zone(s) zoneB

To modify groupnet attributes, including the name, supported DNS servers, and DNS configuration settings, run the isi network groupnet modify command. For example:



# isi network groupnet modify groupnet1 –dns-search=lab.isilon.com,test.isilon.com

To retrieve and sort a list of groupnets by ID in descending order, run the isi network groupnets list command. For example:



# isi network groupnets list –sort=id –descending

ID DNS Cache DNS Search DNS Servers Subnets

————————————————————

groupnet2 True lab.isilon.com 192.168.2.75 subnet2

  1. 192.168.2.67 subnet4

groupnet1 True 192.168.2.92 subnet1

  1. 192.168.2.83 subnet3

groupnet0 False 192.168.2.11 subnet0

  1. 192.168.2.20

——–

Total: 3



To view the details of a specific groupnet, run the isi network groupnets view command. For example:



# isi network groupnets view groupnet1

ID: groupnet1

Name: groupnet1

Description: Lab storage groupnet

DNS Cache Enabled: True

DNS Options: –

DNS Search: lab.isilon.com

DNS Servers: 192.168.1.75, 172.16.2.67

Server Side DNS Search: True

Subnets: subnet1, subnet3

Groupnet information can also be viewed, created, deleted and modified from the WebUI by navigating to: Cluster Management -> Network Configuration -> External Network

groupnet_4.jpg

So there we have it. The groupnet is one of the networking cornerstones of the OneFS multi-tenancy stack.



The OneFS protocols and services that are multi-tenant aware and can work with multiple groupnets include:

  • SMB
  • NFS (including NSM and NLM)
  • HDFS
  • Authentication (AD, LDAP, NIS, Kerberos)

Related: