Reputation
Top tag
Next privilege 50 Rep.
Comment everywhere
Badges
4
Newest
 Teacher
Impact
~951 people reached

  • 0 posts edited
  • 0 helpful flags
  • 0 votes cast
Jun
16
comment Office 365 Exchange Rules - Delete on Arrive
yeah, this way also has the benefit of having items in the bin for when that manager or clueless tech has an important email sent to that account for "reasons"...
Jun
14
awarded  Teacher
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
so does that new explanation make any more sense?
Jun
13
answered Office 365 Exchange Rules - Delete on Arrive
Jun
13
awarded  Commentator
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
Not for nothing but I didn't earn the AD and DNS badges for not understanding AD and DNS. I'm just not understanding what you're asking and what your end goal is here. No worries, I'm frustrated at myself for not being able to explain it better without giving too much away...
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
So, one group wants to set the suffix to match addomain.com and another group wants to configure it corpdomain.net. (It's currently corpdomain.net, and the one group wants it changed to match ad. But I'm having trouble finding anything that definitively states who's correct.)
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
Here lets try this: All our external facing services use corpname.com. They are really unimportant to this though. Then we have ADDomain.com as our active directory domain. So we have servers like corpweb01.addomain.com and corpweb03.addomain.com. Then we have the connivance domain corpdomain.net. So we use utility named UtilityX hosted on corpweb03.addomain.com Because we like things to be pretty for the users we setup utilityx.corpdomain.net because its not external facing, if it were it would be setup for utilityx.corpdomain.com.
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
and then failover to server01.example.com when it cannot find server01.example2.com? erm, actually it doesn't fail over. If you set the connection specific suffix to example2.com it tries to find server01.example2.com, fails and then you can't resolv the server.
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
So a domain (example.com) joined machine with the connection specific suffix set to example2.com will not search for a non-fqdn of server01 first for server01.example2.com and then failover to server01.example.com when it cannot find server01.example2.com? Isn't it better to search the primary source of information first instead of the secondary?
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
If you intend to host an internal DNS zone named example.com then you're setting yourself up for headaches Then just go with it being example2.com. I don't really get why you think it'll be such an issue but that's really not important. The point is its a domain name other than the ad domain name.
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
If when everything was configured the FQDN was used it wouldn't be so much of an issue, and in time we'll get there but one side thinks there are technical reasons that affect all manor of network performance from machine startup time to user logins and the other side disagrees and wants it set one way for obfuscation of the real domain name.
Jun
13
comment AD Best Practice for the connection specific DNS suffix network setting
Are you asking what the DNS suffix should be for non-AD hosts? No, ad joined machines, joined to ad.example.com Why do you have an internal example.com DNS zone? That domain isn't used externally so that's not a problem. Reason was included in the question though.
Jun
13
revised AD Best Practice for the connection specific DNS suffix network setting
tags changed
Jun
13
asked AD Best Practice for the connection specific DNS suffix network setting
Dec
7
awarded  Editor
Dec
7
revised Trouble with Remote Desktop pulling through printers. Drive Redirection works, and the ports created but not the printers
added updates
Dec
7
comment Trouble with Remote Desktop pulling through printers. Drive Redirection works, and the ports created but not the printers
Yup. We've had Microsoft looking into it the past two days. They are just as stumped.
Dec
3
comment Trouble with Remote Desktop pulling through printers. Drive Redirection works, and the ports created but not the printers
I've installed the drivers but thats no longer really necessary with RDSs easyprint support. On the dev server I mentioned it all works without touching print drivers. Users are on a mix of local and on the other side of a VPN. The dev server works for users on both sides. We've been working around it by sharing the users local printer, and connecting to the share but that's a lot of extra work that shouldn't be required.
Dec
3
asked Trouble with Remote Desktop pulling through printers. Drive Redirection works, and the ports created but not the printers