Could you instruct them to browse to %logonserver%\netlogon to make their changes? Or is the testing being done from a different site?
- Sean On Thu, Jan 7, 2016 at 5:45 AM, James Rankin <[email protected]> wrote: > Yes, looks like that’s my other option. > > > > Depends which option I can sneak in most easily J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David McSpadden > *Sent:* 07 January 2016 14:43 > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > Best guess, yeah that’s what I would do. > > Actually what I have done in the past when I want a ‘fix’ > > In right now. > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *James Rankin > *Sent:* Thursday, January 7, 2016 9:40 AM > > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > What these users are doing is making changes to some test profiles in the > netlogon share. They are then “logging on” to test the changes they’ve > made, which are meant to use these profiles, and are reporting issues to > the project team. However the real issue is simply they are making the > changes on remote DCs and when they’re logging on those changes aren’t > replicated to the local DCs (yet). > > > > Maybe I should write a script to robocopy all of the profiles across the > DCs and get them to run that every time they make a change…would make my > life easier J > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *David McSpadden > *Sent:* 07 January 2016 14:36 > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > Ok, I am being dense. > > If you make a change on DC 1 netlogon doesn’t that replicate to DC x’s??? > > So they are not really only affecting the one DC? > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *James Rankin > *Sent:* Thursday, January 7, 2016 9:33 AM > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > Unfortunately fixing their AD is out of scope for my current assignment. > Despite the fact I’ve warned many times that a sub-par AD will have > knock-on effects on the performance of their EUC project infrastructure. > > > > Just wondering if I could “force” these test users to resolve to a local > DC by using hosts files or some such like in the meantime, just to keep the > waters from getting (even more!) muddied…of course then they’d probably > forget all about the files and have another issue on their hands when the > DCs in question were decommissioned… > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *David McSpadden > *Sent:* 07 January 2016 14:29 > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > Here is something that I run every morning to for peace of mind: > > ping server.a.mydomain>output.log > > ping server.b.mydomain >>output.log > > ping server.c.mydomain >>output.log > > ping server.d.mydomain >>output.log > > ping server.e.mydomain >>output.log > > repadmin /showrepl>>output.log > > repadmin /replsummary>>output.log > > dcdiag /s: server.a.mydomain /v>>output.log > > dcdiag /s: server.b.mydomain /v>>output.log > > dcdiag /s: server.c.mydomain /v>>output.log > > dcdiag /s: server.d.mydomain /v>>output.log > > dcdiag /s: server.e.mydomain /v>>output.log > > I review the output.log and look for long or failed replication or pings. > > Usually the replsummary section gives the best info. > > Not sure if this will help you but it may give you a baseline on how > things are working in your environment? > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Gavin Wilby > *Sent:* Thursday, January 7, 2016 9:24 AM > *To:* '[email protected]' <[email protected]> > *Subject:* RE: [NTSysADM] AD question > > > > Isn’t it 90 minute replication between controllers by default? > > > > *Gavin Wilby* > > *IT Support Engineer* > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Kennedy, Jim > *Sent:* 07 January 2016 14:18 > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > Makes no difference. > > > > Is the real issue here that there are ‘big’ delays in replication? > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *James Rankin > *Sent:* Thursday, January 7, 2016 9:17 AM > *To:* [email protected] > *Subject:* RE: [NTSysADM] AD question > > > > I’m just using the short domain name rather than FQDN – does that make a > difference? > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Andrew S. Baker > *Sent:* 07 January 2016 14:13 > *To:* ntsysadm <[email protected]> > *Subject:* Re: [NTSysADM] AD question > > > > If you browse to \\fqdn\someshare, where you end up is determined by DNS > resolution. > > > > \\contoso.com\NetLogon will be resolved to \\some.contoso.dc.ip\NetLogon > and then your system will go there. > > > > > > > > *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> > *Providing Virtual CIO Services (IT Operations & Information Security) for > the SMB market…* > > * GPG: *1AF3 EEC3 7C3C E88E B0EF 4319 8F28 A483 A182 EF3A > > > > On Thu, Jan 7, 2016 at 7:32 AM, James Rankin <[email protected]> wrote: > > A question for the AD masters out there… > > > > If I browse to the \\DOMAIN\netlogon share, how is the DC I browse to in > this instance defined? I’m fairly sure it isn’t the server specified in the > %LOGONSERVER% variable. Got users who are changing things in the NETLOGON > share and they’re finding big delays in seeing these updates because > they’re hitting servers in different physical sites. > > > > Am I right in thinking it depends in how subnets are configured in Sites > and Services? Or way off base? > > > Cheers, > > > > > > > > *James Rankin* > > EUC Director | HTG TaloSys | 07809 668579 | [email protected] > > One Trinity Green, Eldon Street, South Shields, Tyne & Wear, NE33 1SA > > Tel: 0191 481 3489 > > Email address: [email protected] > > Website: www.talosys.co.uk > > [image: phpy9YoGNAM] > > > > > > SMP Partners Limited, SMP Trustees Limited and SMP Fund Services Limited > are licensed by the Isle of Man Financial Services Authority. SMP > Accounting & Tax Limited is a member of the ICAEW Practice Assurance Scheme. > > SMP Partners Limited registered in the Isle of Man, Company Registration > No: 000908V > Directors: M.W. Denton, M.J. Derbyshire, S.E McGowan, O. Peck, J.J. Scott, > S.J. Turner > > SMP Trustees Limited registered in the Isle of Man, Company Registration > No: 068396C > Directors: A.C. Baggesen, J.M. Cubbon, M.W. Denton, K.M. Goldie, O Peck, > J. Watterson > > SMP Fund Services Limited registered in the Isle of Man, Company > Registration No: 120288C > Directors: V. Campbell, R.K. Corkill, M.W. Denton, D.A. Manser, S.E > McGowan, J.J. Scott > > SMP Accounting & Tax Limited registered in the Isle of Man, Company > Registration No: 001316V > Directors: I.F. Begley, A.J. Dowling, P. Duchars, J.J. Scott, S.J. Turner > > SMP Capital Markets Limited registered in the Isle of Man, Company > Registration No: 002438V > Directors: M.W. Denton, M.J. Derbyshire, D.F Hudson, S.E McGowan, O. Peck, > J.J. Scott. > > SMP Partners Limited, SMP Trustees Limited, SMP Fund Services Limited, SMP > Accounting & Tax Limited and SMP Capital Markets Limited are members of the > SMP Partners Group of Companies. > > > > This email is confidential and is subject to disclaimers. Details can be > found at: http://www.smppartners.com/disclaimer.html > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited. > > > > Please consider the environment before printing this email. > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited. > > > > Please consider the environment before printing this email. > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited. > > > > Please consider the environment before printing this email. >
