SBS 2003 - Required DNS Records?


Recommended Posts

Hello,

Im trying to setup a test version of SBS 2003 R2, using VMware Workstation 7 (Windows 7 x64 is the host).

I have gone through the install fine, i then went on to using the configuartion wizards to set up email, VPN and RWW. In the connect to internet and email wizard, i created the web server certificate as: servername.domain.co.uk

I have set up appropiate port forwarding rules in my router (Netgear DG834PN).

I set up the SBS VM with the, say, domain.local. The domain that i want to use with this (for email, VPN and RWW) is domain.co.uk. On the host where domain.co.uk is hosted, i have setup the following DNS records (see attached).

First of all, do these look correct? Do i need any more?

Can someone explain, the @ in the MX record (and the @ in the A record)? Further, i do not see understand if i have to have my mail.domain.co.uk match my servername.domain.co.uk - does that make sense?

Sorry for the confusing question, please ask anything that i didnt make clear.

Cheers

post-225317-1259089090_thumb.png

Link to comment
https://www.neowin.net/forum/topic/848850-sbs-2003-required-dns-records/
Share on other sites

The broken english is a little hard to understand when asking a question. I will answer to the best of my understanding the way the questions were asked.

Everything looks fine with your DNS, you don't need any more entries. VPN, mail, and webmail are all going to go through your mail.x.x.

MX record = Mail eXchange, this is how the internet knows where to route mail. The MX record has to point to an A record. The @ is your main domain ip address, if you just type in domain.co.uk it will direct to that IP Address.

"Further, i do not see understand if i have to have my mail.domain.co.uk match my servername.domain.co.uk - does that make sense?" <---- I don't really understand this question but will give it my best, The A record is just a friendly name on the internet, it has absolutly nothing to do with your internal naming conventions. In otherwords, it does not have to match your computer name as it doesn't resolve to an internal address, it resolves to your external address (external to your network or vmware network).

Hi,

Thanks for the reply (and appologies for the confusion in my question). The problem is i was just not sure what was wrong!

I understand the DNS record setup now (i think!). What i was trying to ask was whether in the SBS CEICW, where you create the webserver certificate and have to supply the FQDN of the server, does this (say servername.domain.co.uk) have to match what you have setup the MX record as. I now undertsand that the FQDN that you set in the CEICW is kinda arbitrary, because as long as you setup a matching A record in the DNS then it will all be fine to access RWW etc (so you can then have a separate MX record, say mail.domain.co.uk for mail - as long as that also has a matching A record to the external IP).

I have attached a screenshot of my new DNS records for clarity (78.xxx.xxx.xxx is the external IP of the router. 195.xxx.xxx.xxx is the IP used for web hosting - which is unrelated to any of this)

Now the problem... When i type: https://portal.domain.co.uk/remote all i get is a Server Not Responding page. I have setup the port forwarding correctly (i believe), as when i try to reach this address, i then see a log entry in the router control panel along the line of:

Wed, 2009-11-25 19:55:34 - TCP Packet - Source:192.168.0.2,63874 Destination:78.***.***.***,443 - [HTTPS rule match]

So the DNS is obviously routing correctly. Ive confirmed the internal IP of the server (192.168.0.10) is set, and this matches the port forwarding rules. Ive disabled the firewall on the Windows 7 host, and the SBS 2003 guest doesnt have a firewall becuase it only has one NIC (?). So why doesnt it work?!

Once again, sorry for the long windedness and any confusion i am / have caused!

post-225317-1259179574_thumb.png

You will need to have your certificate reflect the outside fqdn. If you want you can have the inside fqdn so you don't get the certificate errors on the inside of the network, completely up to you in this regard if only a select amout of users are going to be accessing it from the inside.

If you are trying to access the server from the inside (behind the firewall) with the outside address (trying to go out the in or in the out, however way you want to see it), your router is going to have an issue with that. It drops the packet. Easiest way is to make a dns forward entry for domain.co.uk and an A record under that for portal pointing to the internal ip address.

Thanks for the reply.

I appreciate what you say about trying to access the VM inside the router (loopback?) Anyways, i tried on a couple of other computers (not behind the router) and the request still times out... yet i still get the requests logged in the router? For example:

Thu, 2009-11-26 22:50:06 - TCP Packet - Source:87.127.***.***,52785 Destination:78.***.***.***,443 - [HTTPS rule match] - source is not inside the network!

My port forwarding rules are correct, and the 192.168.0.10 that they forward to (the server) is the IP of the server - what am i missing?!

It has to be outside the inside interface of the router. In other words on the public ip segment. If you want it to answer behind the router, any pc behind the router not just behind the vmware server virtual ip range, you would have to put it in the internal DNS server.

I am attaching a very crude drawing but this is basically what you are trying to accomplish, and it is failing on coming back into the router.

post-118098-1259288857_thumb.jpg

Edited by sc302

Hey

I really appreciate all the help but I finally managed to crack it! I was going crazy because I knew my port forwarding rules were set up correctly, so I simply went to a previous snap shot of the SBS VM (before I ran CEICW) and ran it once more and suddenly every thing worked! Looks like rerunning the wizard over and over isn't the thing to do!

On a side note, just curious about how I would go

about setting up some dns so users could type:

owa.domain.co.uk and being sent to portal.domain.co.uk/reomote

rww.domain.co.uk and being sent to portal.domain.co.uk/exchange

Can this be done? Does it require CNAMEs?

Thanks again for all your help. Much appreciated.

I am assuming that you have an internal dns server (if you are using AD you have to), Put in another forward zone matching your external domain name, then put in an a record for portal, owa, and rww. it is not going to default to the subdirectory exchange or remote. you could put in a webpage at portal that has the links pointing to exchange or remote. You can have the default web page automatically point to one or the other when the page is hit, but that is about it.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • That's not clickbait. Clickbait is headlines like, "You'll never guess what this person looks like now" for example. For goodness sake, take a look around the internet if you think this is clickbait. How do sites survive if people don't click through to articles? How many people in all honesty would have clicked this if it had your suggested headline? You and those upvoting your post won't be happy until the web is a couple of hundred websites all behind a paywall.
    • HopToDesk 1.46.2.0 by Razvan Serea HopToDesk aims to improve the user experience by providing a free, easy-to-use, and secure remote desktop solution for all major device types including Windows PC, Mac, Linux, Android, Chrome Books, iOS, and even Raspberry Pi devices. HopToDesk empowers you to connect, control, and collaborate with ease. Whether you're providing IT support, managing remote teams, or accessing your own devices from anywhere, HopToDesk offers a reliable and secure solution. HopToDesk does not and cannot monitor user activity as the application uses end-to-end encryption for all traffic, and does not make a distinction between personal and business use (both are allowed). Additionally, HopToDesk includes many of the main features of common remote desktop solutions such as Unattended Access, File Transfer, Live Chat, Wake-On-LAN, 2FA, Direct IP access, a Recent Session and Favorite list, and is available in over 20 languages. HopToDesk can run in portable mode or installed on desktop operating systems. Installation is optional, and will install the HopToDesk service which runs in the background and listens for incoming connections, allowing the device to be accessible at all times. Why Choose HopToDesk? Completely Free: Enjoy full access for both personal and commercial use—no hidden fees or limitations. End-to-End Encryption: All communications, including screen sharing, file transfers, and chats, are protected with robust encryption. Open Source: Contribute to and benefit from a transparent and community-driven project. No Account Required: Connect instantly without the need for sign-ups or subscriptions. Core Features Remote Control & Screen Sharing: Effortlessly access and manage remote devices. File Transfer: Securely send and receive files with drag-and-drop simplicity. Live Chat: Communicate in real-time during sessions. Multi-Monitor Support: Navigate multiple screens with ease. Clipboard Synchronization: Copy and paste seamlessly across devices. Wake-on-LAN: Power on remote systems remotely. Session Recording: Document sessions for future reference. Two-Factor Authentication: Enhance security with an additional verification layer. Custom Branding: Personalize your remote sessions with custom avatars. Unattended Access: Connect to devices without requiring user intervention. Network Customization: Adjust settings like TURN relays and signaling servers to suit your environment. Centralized Device Management Utilize the HopToDesk Dashboard to: Monitor device status in real-time. Generate invite links for easy device integration. Customize network settings and synchronize changes effortlessly. Add a personal touch with custom avatars displayed during remote sessions. Download: HopToDesk 64-bit | HopToDesk 32-bit | ~9.0 MB (Freeware) Download: HopToDesk ARM64 | 21.4 MB Link: HopToDesk Home Page | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Or use Epic games and get full games for free. lol Steam and their demos. Thankfully there’s competition
    • Maybe I missed it, but does this say anywhere that the game save bug has been squashed? I haven't encountered it myself, but it would be nice to know I'm good to go. Anyway, amazingly well done game. Mostly more of the same. ...but when the same is best in class with improved graphics and features, then a win.
    • Well when your game flops, you should expect this. If I do bad at work, I would expect a layoff. Less than 1600 people played it on steam. https://steamdb.info/app/1934570/charts/
  • Recent Achievements

    • Reacting Well
      Almohandis earned a badge
      Reacting Well
    • First Post
      Cosminus earned a badge
      First Post
    • One Year In
      ThatGuyOnline earned a badge
      One Year In
    • Week One Done
      Jeroen Wilms earned a badge
      Week One Done
    • Week One Done
      rolfus earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      476
    2. 2
      +Edouard
      181
    3. 3
      PsYcHoKiLLa
      118
    4. 4
      Steven P.
      83
    5. 5
      neufuse
      73
  • Tell a friend

    Love Neowin? Tell a friend!