Solved

Why Duplicate Records in DNS

Posted on 2006-06-20
19
2,505 Views
Last Modified: 2012-08-13
We have DNS setup as AD Integrated Zone, and the No Refresh/Refresh interval is 7 days.
DHCP Lease is 24 hours.

Now I can see in the DNS records differet workstations that have t he same IP address.

if for example I take 2 A records for 2 different workstations that have the same IP address and look at their record time stamp I can find in some cases one of the record  of the 2 different workstations that have the same IP is older than 20 days and in some cases both records for the 2 different workstations of the same IP have a recent time stamp (less than 7 days).

any idea?

thanks



0
Comment
Question by:jskfan
  • 10
  • 9
19 Comments
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16942433
Where (what utility) are you seeing this information??  Any chance that you have static and dynamic entries in DNS? Are any of these computers Laptops?  You can have 2 entrys per workstation if 1 connection is wired and the other wireless.

I need a little more information.
0
 

Author Comment

by:jskfan
ID: 16942841
this info is in DNS zone, and the machines are wired and not laptops.
0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16942946
So you are seeing 2 A records with the same IP address and different host names - correct?  And you are sure that they are dynamic entrys?

I just want to be sure that I understand your question.

Sounds to me like your DCHP pool is kinda full.  You only allow the lease to be 1 day.  You don't allow changes to your DNS records for 7 days.  So, you have computers getting issued the same IP address from DHCP and they are registering themselves in DNS - normal.

Can you increase the DHCP Lease length?  Are you short on addresses?   Can you increase the number of addresses in the DHCP pool?

It is OK to have 2 A records with the same IP address and different host names - if you design it that way.  For example, It would allow you to call your web server by www.domain.com and just domain.com.

Still need more info, Thanks.
0
 

Author Comment

by:jskfan
ID: 16943880
I think DHCP lease if it's for one day or more , clients still don't refresh the DNS record for 7 days. So I don't think DHCP lease is an issue.

I don't understand what you meant by the following statement:

<<<<It is OK to have 2 A records with the same IP address and different host names - if you design it that way.  For example, It would allow you to call your web server by www.domain.com and just domain.com.>>>>>>>>>>>
0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16944056
jskfan - you are correct about the updating of DNS but DCHP might still be a part of this problem.

A snip from an website: http://searchwinsystems.techtarget.com/tip/1,289483,sid68_gci1040355,00.html

There are two parts of DDNS that we need to understand before we answer the question: DNS and DHCP.

DHCP process
(Wait a second! I thought we were talking about DNS?) Before we go on about DNS, we first have to understand how DDNS works and why DHCP is important in this process. Dynamic DNS registration happens at two places, either the DHCP client or the DHCP server. It all depends on configuration and client type. For the most part, Windows 2000 clients and above handle their own host name registrations, while the DHCP server handles the PTR registration, except in the case of statically assigned IP addresses, in which case the client will handle both the host name and PTR registrations. In other configurations, the DHCP server can be made to handle the host and PTR registrations. Other clients (NT4, 9x, among others), which are down-level clients, do not interact with the DDNS registration process. However, the DHCP server can be set to handle registration for these clients as well. Okay, now we have an idea of how these records are getting in DDNS. Unfortunately, the way records go in is a lot more efficient than the way they come out. By the way, read Larry Duncan's excellent article, "DNS for Active Directory -- A 10 Minute Primer," to understand what clients like to refresh their records.

DDNS process
There's nothing to stop two records from holding the same IP address or the same host name. A common scenario where this is problematic is image-based workstation/laptop deployments. During a portion of the image process, the client will register as WIN2KIMAGE in DNS, for example, before having the machine name changed later down the process. Another image is started and WIN2KIMAGE is added again with a different IP address. Sooner or later, you end up with 50 PTR records pointing to the same name, WIN2KIMAGE. This same process happens under different situations where a machine will establish a different dynamic IP address, but for some reason, the old reverse-lookup record is not removed. Generally, the DHCP client and server helps clean up these records and, in some configurations, the DHCP server does it all. However, real world experience might tell you that this is not getting done effectively. When this clean up process does not occur properly, stale records reside in DNS.


We still need more information to help solve.
0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16944073
More from that article


1. DNSClient registers with DDNS.
2. No-refresh Interval starts (seven days).
3. DDNS server will not accept re-registration attempts from this client for seven days.
4. No-refresh Interval expires.
5. Refresh Interval starts (seven days).
6. DNSClient has seven days to refresh its records before the record is considered stale.
7. Refresh Interval expires.
8. Scavenging process removes record.
0
 

Author Comment

by:jskfan
ID: 16944138
what more info do you need?
0
 

Author Comment

by:jskfan
ID: 16944154
I still don't understand why 2 workstations would register the same IP address.
0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16945602
Please read my previous posts.  

Are you just using dynamic DNS or do you have static entires?
How many available addresses do you have in your DHCP pool?
Are you having a specific problem or are you concerned that you see to hosts with the same IP?


In your case when you have 2 addresses with the same IP here is one of many possible reasons:

Workstation A gets a DHCP address on Monday 12:00pm and registers an A record in DNS.  If workstation A is on 12 hours later (1/2 the lease time) it will try to renew the address.  If workstation A is not on or the DHCP server is not available, workstation A will try to renew the address at (7/8 of the lease).  24 hours (the lease time) later the client will not be able to use the address. SO.....
Lets say that workstation A gets a lease for an address and shuts down 2 hours later and does not restart for 2 days.  After 24 hours that address is available to give to workstation B.  Because of how you have DNS set up to not allow changes to DNS for 7 days the client will not (can not) update the DNS record.  DHCP will try to give your workstation A the same address if it can - if you are low on addresses in your DHCP pool it will reuse the address given to workstation a.  When it gets its new address it will dynamically register its address with DNS.  ---- Two hosts with the same IP address in DNS.  I am not saying this is what is happing but it is one of the possibilities.

Hope this helps.....
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Author Comment

by:jskfan
ID: 16945868
I guess we have different understanding in DNS.

When workstation A gets a new IP address, it registers with DNS(DNS creates a new record for it) and DNS replicates the zone to other Active Directory Databases then it put a time stamp on the Record that was created for workstation A (Don't refresh this record for 7 days), if Workstation A shuts downd and doesn't come back online for 14 days DNS will still wait for it to refersh the record and after 14 days the record will be considered stale and the scavenging process will start for that record. so DNS should not let another workstation to have the same IP before it scavenges the old record that held the same IP.

I think even if DHCP runs out of addresses it will not handle an existing IP address to a different Workstation.

Please let me know where I am wrong.




0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16946057

DHCP is involved when you are not running 2000+ clients OR when you configure DHCP to register A and PTR records.  It acts on behalf and registers for the client.  Thats is why you add your DHCP servers to the DnsUpdateProxy Group so when clients are upgraded they can change the records because the DHCP server is not the owner of the DNS record (a issue with using AD DDNS with pre 2000 clients).

AGAIN, I am not saying this is what is happing but it is one possibility!

jskfan: DHCP will reissue address IF the lease has not been renewed (it is expired and the client does not own it).  It will not hand out an address that the client owns (for example, workstation A gets a DHCP lease for 8 days (the default) and the computer is turned off for 6 days.  IT STILL owns the address and DHCP will NOT hand it out.  When the computer starts up is will contact DHCP  and renew the address for 8 more days.  If the computer is not started for 10 days and the DHCP server does not have "extra" IP addresses, it will assign workstations address to workstation b.

I was looking for a MS paper that talks about DHCP lease duration and DDNS scavenging and how to set the lease and scavenging in relationship to each other - I have not found it yet.

Sorry for the long post.  This is an abstract from a Windows 2000 White paper:


Dynamic Update of DNS Records
Every computer running Windows 2000 attempts the registration of its A and PTR records. The service that actually generates the DNS dynamic updates is the DHCP client. The DHCP client service runs on every machine regardless of whether it is configured as DHCP client or not.

The dynamic update algorithm differs depending on the type of client network adapter engaging in the dynamic update process. The following three scenarios will be examined:

DHCP client
Statically configured client
RAS client
DHCP Client
When a Windows 2000 DHCP client bootstraps, it negotiates the dynamic update procedure with a DHCP server. By default, the DHCP client always proposes that it update the A resource record, while the DHCP server updates the PTR resource record.

The Windows 2000 DHCP server can be configured to "Update DNS server according to client request" (default setting), or "Always update forward and reverse look-ups."

If the DHCP server is configured to Always update forward and reverse lookups, it will update both A and PTR RRs itself regardless of the DHCP client's request.

If the DHCP server is disabled to perform dynamic updates, the DHCP client will attempt to update both A and PTR RRs itself.

At expiration of the IP address lease, these records must be removed from the appropriate zones. Dynamic cleanup requires that the records are deleted by the registering computer(s)—in this case the DHCP client or server or both—that created them. Thus, if the machine that created an A or PTR resource record is disconnected from the network before the lease expiration, the corresponding resource records may become stale. Since the DHCP server is the owner of the IP address it is encouraged that DHCP servers perform PTR records registration when possible.

Mixed Environment

It is possible that a Windows 2000 DHCP client will try to negotiate the dynamic update procedure with the Windows NT 4.0 DHCP server (or any other DHCP server that doesn't support DNS dynamic updates). Since the Windows NT 4.0 DHCP server does not support dynamic updates, the Windows 2000 DHCP client will have to update both the A and PTR RRs itself.

In the reverse situation, with down-level clients (for example, Windows 95, Windows 98, and Windows NT 4.0), the Windows 2000 DHCP server after negotiation of a lease with a client, will register both the A and PTR records in DNS, if the "Do updates for down-level DHCP clients" option is selected in a configuration of the DHCP server.

DHCP Server Considerations

In addition, when the DHCP client's lease expires, the DHCP server will remove the client's PTR RR. Also, the DHCP server will remove the corresponding A records if configured to "Discard forward lookups when leases expire."

Statically Configured Client
A statically configured client does not communicate with the DHCP server and dynamically updates both A and PTR RRs every time it boots up, changes its IP address or per-adapter domain name.

RAS Client
A RAS client behaves in the same manner as a statically configured client in that no interaction occurs between the client and the DHCP server. The client is responsible for dynamically updating both A and PTR RRs. The RAS client attempts to delete both records before closing the connection, but the records remain stale if the update failed for some reason (for example, the DNS server was not running at that time). The records also remain stale if the line goes down unexpectedly. In these cases a RAS server attempts deregistration of the corresponding PTR record.

Client Reregistration
One of the benefits of Dynamic Update is its ability to reregister RRs in DNS, which provides a certain level of fault tolerance in case some records in a zone become corrupted. DHCP server automatically reregisters the DNS records that it registered upon renewal of the lease. The Windows 2000-based clients reregister their DNS records every 24 hours. This value could be changed by specifying REG_DWORD DefaultRegistrationRefreshInterval value under the HKLM\System\CurrentControlSet\Services\Tcpip\Parameters registry key.

Note: When a client registers in DNS, the associated RRs include TTL, which by default is set to 20 minutes. This can be changed by specifying REG_DWORD DefaultRegistrationTtl value under the HKLM\System\CurrentControlSet\
Services\Tcpip\Parameters registry key.

Dealing with Name Conflicts
If, during Dynamic Update registration, a client discovers that its name is already registered in DNS with an IP address that belongs to some other machine, by default the client deletes the existing registration and registers its own RRs in its place. By using the appropriate registry key, this behavior may be disabled and the client will back out of the registration process and log the error in the Event Viewer. The first scenario allows you to remove stale records, but is vulnerable to malicious attacks. The second scenario has opposite effect. The problem of deletion of existing records when name collision takes place is resolved by using Secure Dynamic Updates (described in the next section). In this case only the owner of the existing record can update it.

Secure Dynamic Update
The DS integrated zones may be configured to use a Secure Dynamic Update. Access Control Lists, as mentioned in "Controlling Access to Zones," specify the list of groups or users allowed to update resource records in such zones. The Windows 2000 DNS implementation of the Secure Dynamic Update is based on the algorithm defined in the Internet Draft "GSS Algorithm for TSIG (GSS-TSIG)." This algorithm is based on the Generic Security Service Application Program Interface (GSS-API) specified in RFC 2078. It provides security services independently of the underlying security mechanism, and separates the security services into the following processes:

Establishing a security context by passing security tokens.
Once a security context has been established, it has a finite lifetime during which it can be used to create and verify transaction signatures on messages between the two parties


Aging and Scavenging
With dynamic update, records are automatically added to the zone when computers and domain controllers are added. However, in some cases, they are not automatically deleted.

Having many stale resource records presents a few different problems. Stale resource records take up space on the server, and a server might use a stale resource record to answer a query. As a result, DNS server performance suffers.

To solve these problems, the Windows 2000 DNS server can scavenge stale records; that is, it can search the database for records that have aged and delete them. Administrators can control aging and scavenging by specifying the following:

Which servers can scavenge zones
Which zones can be scavenged
Which records must be scavenged if they become stale
The DNS server uses an algorithm that ensures that it does not accidentally scavenge a record that must remain, provided that you configure all the parameters correctly. By default, the scavenging mechanism is disabled. Do not enable it unless you are absolutely certain that you understand all the parameters. Otherwise, you might accidentally configure the server to delete records that it should retain. If a name is accidentally deleted, not only do users fail to resolve queries for that name, but also, any user can create that name in DNS and then take ownership of it, even on zones configured for secure dynamic update.

You can manually enable or disable aging and scavenging on a per-server, per-zone, or per-record basis. You can also enable aging for sets of records by using Dnscmd.exe. Keep in mind that if you enable scavenging on a record that is not dynamically updated, the record will be deleted if it is not periodically refreshed, and you must recreate the record if it is still needed.

If scavenging is disabled on a standard zone and you enable scavenging, the server does not scavenge records that existed before you enabled scavenging. The server does not scavenge those records even if you convert the zone to an Active Directory–integrated zone first. To enable scavenging of such records, use Dnscmd.exe.

Aging and Scavenging Parameters
The Windows 2000 DNS server uses a record timestamp, along with parameters that you configure, to determine when to scavenge records.

The table below lists the zone parameters that affect when records are scavenged. You configure these properties on the zone.

Aging and Scavenging Parameters for Zones

Zone Parameter
 Description
 Configuration Tool
 Notes
 
No-refresh interval

 Time interval, after the last time a record's timestamp has been refreshed, during which the server does not accept refreshes for the record. (The server still accepts updates.)

 DNS console and Dnscmd.exe

 When an Active Directory–integrated zone is created, this parameter is set to the DNS server's parameter Default no-refresh interval.
This parameter replicates through Active Directory replication.

 
Refresh interval

 The refresh interval comes after the no-refresh interval. On expiration of the no-refresh interval, the server begins accepting refreshes for the record. After the refresh interval expires, the DNS server may scavenge records that have not been refreshed during or after the refresh interval.

 DNS console and Dnscmd.exe

 When an Active Directory–integrated zone is created, this parameter is set to the DNS server's parameter DefaultRefreshInterval.
This parameter is replicated by Active Directory.

 
Enable Scavenging

 This flag indicates whether aging and scavenging is enabled for the records in the zone.

 DNS console and Dnscmd.exe

 When an Active Directory–integrated zone is created, this parameter is set to the DNS server's parameter DefaultEnableScavenging.
This parameter is replicated by Active Directory.

 
ScavengingServers

 This parameter determines which servers can scavenge records in this zone.

 Only Dnscmd.exe

 This parameter is replicated by Active Directory.

 
Start scavenging


 This parameter determines when a server can start scavenging of this zone.

 Not configurable

 This parameter is not replicated by Active Directory.

 


The table below lists the server parameters that affect when records are scavenged. You set these parameters on the server.

Aging and Scavenging Parameters for Servers

Server Parameter
 Description
 Configuration Tool
 Notes
 
Default no-refresh interval

 This value specifies the no-refresh interval that is used by default for an Active Directory–integrated zone created on this server.

 DNS console (shown as No-refresh interval) and Dnscmd.exe

 By default, this is 7 days.

 
Default refresh interval

 This value specifies the refresh interval that is used by default for an Active Directory–integrated zone created on this server.

 DNS console (shown as Refresh interval) and Dnscmd.exe

 By default, this is 7 days.

 
Default Enable Scavenging


 This value specifies the Enable Scavenging parameter that is used by default for an Active Directory–integrated zone created on this server.

 DNS console (shown as Enable scavenging)and Dnscmd.exe

 By default, scavenging is disabled.

 
Enable scavenging


 This flag specifies whether the DNS server can perform scavenging of stale records. If scavenging is enabled on a server, it automatically repeats scavenging as often as specified in the Scavenging Period parameter.

 DNS console, Advanced View (shown as Enable automatic scavenging of stale records) and Dnscmd.exe

 By default, scavenging is disabled.

 
Scavenging Period

 This period specifies how often a DNS server performs scavenging.

 DNS console, Advanced View (shown as Scavenging Period) and Dnscmd.exe

 By default, this is 7 days.

 

Record Life Span
The Figure below shows the life span of a scavengeable record.


If your browser does not support inline frames, click here to view on a separate page.

When a record is created or refreshed on an Active Directory–integrated zone or on a standard primary zone for which scavenging is enabled, a record's timestamp is written.

Because of the addition of the timestamp, a standard primary zone file for which scavenging is enabled has a format slightly different from a standard DNS zone file. This does not cause any problems with zone transfer. However, you cannot copy a standard zone file for which scavenging is enabled to a non-Windows 2000-based DNS server.

The value of the timestamp is the time when the record was created or the record was last refreshed. If the record belongs to an Active Directory–integrated zone, then every time the timestamp is refreshed, the record is replicated to other domain controllers in the domain.

By default, the timestamps of records that are created by any method other than dynamic update are set to zero. A zero value indicates that the timestamp must not be refreshed and the record must not be scavenged. An Administrator can manually enable aging of such records.

After the record is refreshed, it cannot be refreshed again for the period specified by the no-refresh interval. The no-refresh interval, a zone parameter, prevents unnecessary Active Directory replication traffic.

However, the record can still be updated during the no-refresh interval. If a dynamic update request requires record modification, it is considered an update. If it does not require record modifications, it is considered a refresh. Therefore, prerequisite-only updates—updates that include a list of prerequisites but no zone changes—are also considered refreshes.

The no-refresh interval is followed by the refresh interval. After the expiration of the no-refresh interval, the server begins to accept refreshes. The record can be refreshed as long as the current time is greater than the value of the timestamp plus the no-refresh interval. When the server accepts a refresh or an update, the value of the timestamp changes to the current time.

Next, after the expiration of the refresh interval, the server can scavenge the record if it has not been refreshed. The record can be scavenged if the current time is greater than the value of the timestamp plus the value of the no-refresh interval plus the value of the refresh interval. However, the server does not necessarily scavenge the record at that time. The time at which records are scavenged depends on several server parameters.

Scavenging Algorithm
The server can be configured to perform scavenging automatically, using a fixed frequency. In addition, you can manually trigger scavenging on a server to perform immediate scavenging. When scavenging starts, the server attempts to scavenge all primary zones and succeeds if all the following conditions are met:

The EnableScavenging parameter is set to 1 on the server.
The EnableScavenging parameter is set to 1 on the zone.
Dynamic update is enabled on the zone.
The zone parameter ScavengingServers is not specified or contains the IP address of this server.
The current time is greater than the value of the zone parameter StartScavenging.
The server sets StartScavenging whenever any of the following events occur:

Dynamic update is turned on.
EnableScavenging is set from 0 to 1 on the zone.
The zone is loaded.
The zone is resumed.
StartScavenging is equal to the time that one of the preceding events occurs plus the amount of time specified in the refresh interval for the zone. This prevents a problem that can occur if the client is unable to refresh records because the zone isn't available—for example, if the zone is paused or the server is not working. If that happens and the server does not use StartScavenging, the server could scavenge the zone before the client has a chance to update the record.

When the server scavenges a zone, it examines all the records in the zone one by one. If the timestamp is not zero, and the current time is later than the time specified in the timestamp for the record plus the no-refresh and refresh intervals for the zone, it deletes the record. All other records are unaffected by the scavenging procedure.

Configuring Scavenging Parameters
This section discusses issues you must consider when configuring scavenging parameters.

To ensure that no records are deleted before the dynamic update client has time to refresh them, the refresh interval must be greater than the refresh period for each record subjected to scavenging within a zone. Many different services might refresh records at different intervals; for example, Netlogon refreshes records once an hour, cluster servers generally refresh records every 15 to 20 minutes, DHCP servers refresh records at renewal of IP address leases, and Windows 2000–based computers refresh their A and PTR resource records every 24 hours.

Usually, the DHCP service requires the longest refresh interval of all services. If you are using the Windows 2000 DHCP service, you can use the default scavenging and aging values. If you are using another DHCP server, you might need to modify the defaults.

The longer you make the no-refresh and refresh intervals, the longer stale records remain. Therefore, you might want to make those intervals as short as is reasonable. However, if you make the no-refresh interval too short, you might cause unnecessary replication by Active Directory.

0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16946092
http://www.microsoft.com/technet/prodtechnol/windows2000serv/plan/w2kdns2.mspx

is the link to the white paper.....Sorry I did not find the link sooner.  I am still looking for the documentation that talks about the ratio between DHCP lease and scavenging.


Are you having a specific problem or are you concerned that you see to hosts with the same IP?
Are you just using dynamic DNS or do you have static entires?
How many available addresses do you have in your DHCP pool?
0
 

Author Comment

by:jskfan
ID: 16946250
I have read part of your thread, and it says :
<<The problem of deletion of existing records when name collision takes place is resolved by using Secure Dynamic Updates (described in the next section). In this case only the owner of the existing record can update it. >>>>


 in our network Secure Dynamic Update is used, but I don't know why one workstation can register with existing IP address
0
 

Author Comment

by:jskfan
ID: 16946264
I might agree with you about the DHCP lease which is too short compared to the refresh interval and No Refresh.
0
 
LVL 6

Accepted Solution

by:
e_vanheel earned 400 total points
ID: 16946620
I believe that the secure update only pertains to the zone updates / zone transfers and client registration - it uses the AD / Kerberos so your zone transfers can not be sniffed on the wire, the same way it does the AD.  In DDNS only the owner can change the existing record (unless the DHCP server is the owner and the server is a member of the DnsUpdateProxy Group)

I don't think DNS is smart enough to say "can not register" someone else has that IP address.  Try it.  You can create an A record for WS1 @ 10.0.0.1 and WS2 @ 10.0.0.1.  

Are you having a specific problem or are you concerned that you see to hosts with the same IP?
Where are you seeing the timestamps? What utility?
Are you just using dynamic DNS or do you have static entires?
How many available addresses do you have in your DHCP pool?

0
 

Author Comment

by:jskfan
ID: 16946830
<<<Are you having a specific problem or are you concerned that you see to hosts with the same IP?>>>

sometimes you try to remote to X computer and ou end up remotin to Y computer

<<<<Where are you seeing the timestamps? What utility?>>>
in the DNS Console--Click View-Advanced. then if you go to properties of the record it will show you the Time Stamp.

<<<Are you just using dynamic DNS or do you have static entires?>>>
If I understand you we use Dynamic update

<<<How many available addresses do you have in your DHCP pool>>>
we have different pools (scopes), but I still agree with you for the short life of the DHCP lease compared to the Refresh/No Refresh interval.
I also may need to mention to you, that our network clients were W2K Pro and the Techs used ghost image to roll over to WXP, I have heard this can cause an issue.




0
 

Author Comment

by:jskfan
ID: 16946860
By the way is there any event log on DHCP server or somewhere else where it says DHCP is running out of IP addresses?
0
 
LVL 6

Expert Comment

by:e_vanheel
ID: 16952406
In the DHCP manager click on your server and display statistics to see how many addresses you have left.  Why did you change the default length of the DHCP reservation?  The default is 8 days.

In DNS have you tried to delete the incorrect address from the database?
0
 

Author Comment

by:jskfan
ID: 16952900
The company has set up the lease to 24 hrs

in DNS even they delete manually the incorect records they get them back.

this is why I said it might be th lease is too short.

I believe though that the imaging also has caused to have incorrect records


0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Suggested Solutions

I've written instructions for one router type, but this principle may be useful for others of the same brand and even other brands of router. Problem: I had an issue especially with mobile devices that refused to use DNS information supplied via…
Let’s list some of the technologies that enable smooth teleworking. 
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now