Whew, I know it's been forever since I've updated this blog but I have been insanely busy lately. Started a new job back in June and have been stacked with projects, not to mention documentation!
Anyway, wanted to make some notes on WSUS v3, which I've recently implemented here at Bolinger, Segars, Gilbert & Moss. Firstly, once you install WSUS you're probably thinking: "What is the difference between configuring WSUS vs just using the Microsoft website?" Well, they are completely separate.
Now, before I get too far ahead of myself, WSUS is Windows Server Update Services which can be downloaded for free from Microsoft's website HERE. Basically you install it on a server on your domain with IIS and configure Group Policy settings to point all your client workstations (and servers) to it. For more information on configuring Group Policy for use with WSUS please visit this website.
Now, once you have the WSUS services installed, you'll need to run the wizard on the admin console to configure the products you want to recieve updates for. This is critical, because if you select products you don't need you'll have to sort through them later as there is no way to remove them from your list once downloaded. You can however, rerun the wizard to exclude unwanted software from future updates. Anyway, so then once you've run the wizard, you'll need to manually approve/deny each update (there are quite a few of them) even if your clients already have the update.
I would recommend configuring different groups for different updates such as a group for servers and a group for workstations so you can keep everything organized. Once you have approved some updates, you can either wait until the server asks for updates (provided you have group policy configured to point to the WSUS server) which is about every 16-22 hours by default, or you can test your setup by connecting to a server or workstation and opening up the command line and typing 'wuauclt.exe /detectnow'. This will manually force a query to the WSUS server for approved updates.
Ok, you already have everything set up, now to deal with the Windows Updates website. You may or may not want users connecting to the website to get updates, this is purely a personal or company based mandate. If you do not want users to use the website, you have several options. If you have an internet filter on your network just block the website, otherwise you'll need to configure the GPO setting under 'user configuration/administrative templates/start menu and taskbar/remove links and access to Windows Update'. This basically prevents users from connecting to the Windows Update Web Site and also blocks the activex control used if the user connects to the website manually. Bear in mind this affects administrators and non-administrators alike so use with caution!
Friday, October 24, 2008
Tuesday, February 26, 2008
Troubleshooting MX Host Connectivity
Recently I had an issue arise that is pretty common in today's industry where one domain is unable to send email to another one (or so we think). We need a way to test this and after seeing a buddy of mine do it a couple of years ago I decided to track down how it is done. Plus it makes me feel like an über admin when I do it :-)
To elaborate on the issue, say DomainA cannot seem to send email to DomainB and DomainB returns undeliverables and error messages etc. DomainB states that their MX Host is up and running and they are receiving mail from other domains. DomainA then feeling like a red-headed stepchild calls you (the Mail Admin) asking WTF is going on. You know you are able to send to other domains just fine and want to know what is going on with the relationship between you (DomainA) and DomainB. You need to test a connection from one email address @DomainA to an address @DomainB and you want their MX Host to tell you it's kosher...
Down to business, first thing you need to do is make sure you can get out of the corp firewall over port 25. You won't get anywhere without this ability. Sweet talk your Network folks, whatever just give em your IP and ask to get out over port 25 for a bit of testing. After that, you'll need to find the actual MX Hostname of DomainB. I recommend MXToolBox. Sure NSLOOKUP will do this as well but what if your DNS has the wrong records in the first place? Uh huh, betcha didn't think about that :-) Just go there and put in DomainB's name into the box and whammy! You have their MX Hostnames there in order starting with the primary.
Take the primary MX Hostname and open up a telnet session (hyperterm or command line). Make sure you enable localecho and logging if you want to save the output (set localecho ENTER and then set logfile (path) ENTER) Now open a connection to the MX Host...
This is a very crucial thing to remember, you MUST not have any errors while connected to the MX Host, you will get a syntax error, no backspaces, misspells, and case must be correct. You want to play it slow and easy with the typing here.
Once you are connected to the host, issue the following commands:
This basically tests DomainB's ability to receive email from your domain without any problems. If you get syntax errors, start over, you mistyped something. It happens alot. Other errors are self-explanatory. If you can't talk to DomainB, then they need to address the issue. You might be blacklisted. Otherwise, if everything else is ok, you may need to do an NSLOOKUP to make sure the MX Host is correct. If it is different than what you get when you do an external MX lookup like with the above website, then you need to change your DNS records to match the current one.
I got most of this information from the following websites:
http://exchange.mvps.org/smtp_frames.htm
and
http://technet.microsoft.com/en-us/library/bb123686(EXCHG.80).aspx
To elaborate on the issue, say DomainA cannot seem to send email to DomainB and DomainB returns undeliverables and error messages etc. DomainB states that their MX Host is up and running and they are receiving mail from other domains. DomainA then feeling like a red-headed stepchild calls you (the Mail Admin) asking WTF is going on. You know you are able to send to other domains just fine and want to know what is going on with the relationship between you (DomainA) and DomainB. You need to test a connection from one email address @DomainA to an address @DomainB and you want their MX Host to tell you it's kosher...
Down to business, first thing you need to do is make sure you can get out of the corp firewall over port 25. You won't get anywhere without this ability. Sweet talk your Network folks, whatever just give em your IP and ask to get out over port 25 for a bit of testing. After that, you'll need to find the actual MX Hostname of DomainB. I recommend MXToolBox. Sure NSLOOKUP will do this as well but what if your DNS has the wrong records in the first place? Uh huh, betcha didn't think about that :-) Just go there and put in DomainB's name into the box and whammy! You have their MX Hostnames there in order starting with the primary.
Take the primary MX Hostname and open up a telnet session (hyperterm or command line). Make sure you enable localecho and logging if you want to save the output (set localecho ENTER and then set logfile (path) ENTER) Now open a connection to the MX Host...
This is a very crucial thing to remember, you MUST not have any errors while connected to the MX Host, you will get a syntax error, no backspaces, misspells, and case must be correct. You want to play it slow and easy with the typing here.
Once you are connected to the host, issue the following commands:
helo (your domain here)
Response should be 'OK'
mail from: (your email address here)
Response should be 'OK - (your email address)'
rcpt to: (recipient email address here)
Response should be 'OK - (recipient email address)'
data
Response should be 'Send data. End with CRLF.CRLF'
To: (recipient's display name)(enter)
From: (your display name)(enter)
Subject: (Subject field of Email message)(enter)
(Enter you body text)(enter)(enter) . (enter)
response should be 'OK'
quit
Response should be 'OK'
mail from: (your email address here)
Response should be 'OK - (your email address)'
rcpt to: (recipient email address here)
Response should be 'OK - (recipient email address)'
data
Response should be 'Send data. End with CRLF.CRLF'
To: (recipient's display name)(enter)
From: (your display name)(enter)
Subject: (Subject field of Email message)(enter)
(Enter you body text)(enter)(enter) . (enter)
response should be 'OK'
quit
This basically tests DomainB's ability to receive email from your domain without any problems. If you get syntax errors, start over, you mistyped something. It happens alot. Other errors are self-explanatory. If you can't talk to DomainB, then they need to address the issue. You might be blacklisted. Otherwise, if everything else is ok, you may need to do an NSLOOKUP to make sure the MX Host is correct. If it is different than what you get when you do an external MX lookup like with the above website, then you need to change your DNS records to match the current one.
I got most of this information from the following websites:
http://exchange.mvps.org/smtp_frames.htm
and
http://technet.microsoft.com/en-us/library/bb123686(EXCHG.80).aspx
Monday, September 10, 2007
Setting up an Authoritative Time Server
I received a ticket today regarding an issue Windows Time being out of sync with the phone system, which just so happens to be getting its time from the official Naval time source Stratum server. Now keep in mind we are running a semi-large domain and theoretically our workstations and servers all get their time from the PDC (Primary Domain Controller). Turns out we are in effect 3 minutes fast according to the official US time which can be found here.
So in order to troubleshoot this issue I went to our Primary Domain Controller. If you are unsure which one that may be, you can download the Server 2003 Support Tools and run the NETDOM utility (from command line: "netdom query fsmo") to tell you which server is in fact the PDC. Once you have this information you log onto that server and check the registry settings as defined in this article. To save time and space I won't repeat everything that is in the article but here are some important points:
So this information seemed to check out and all the registry settings were there (see 'Configuring the Windows Time service to use an external source' in the above link) but I was still not able to get the updated time. After looking into the issue further and doing some 'Googling', I found that if you have your Windows Time Service configured in Group Policy and any GPO with this configured is being applied to the Primary Domain Controller, it simply will NOT work. Someone had this very thing configured in our Default Domain Controllers Policy and upon changing the settings to 'Not Configured' and updating the policy on the PDC (from command line: gpupdate /force) I was then able to sync the time without any issues.
When configuring an external time source for your domain always remember to:
-Check to see if any Group Policies with Windows Time Service settings enabled are being applied to the Domain Controllers, if so be sure to set them as Not Configured.
- Make sure you only have your Primary Domain Controller Emulator set as the 'NTP' server as mentioned in the above Microsoft article.
-Follow Microsoft's Best Practices when setting your refresh and correction intervals on the PDC.
If everything is hosed up and you want to start over, just use these commands:
net stop w32time
w32tm /unregister (this will wipe out all Windows Time settings)
w32tm /register
Configure your NTP settings in the Registry
net start w32time
w32tm /resync /rediscover
I happen to use tock.usno.navy.mil as my time server, if you want to check for more, I would recommend downloading and using a utility called NTP Query to test connections to time servers before going through the trouble of modifying your registry. It can be downloaded HERE.
So in order to troubleshoot this issue I went to our Primary Domain Controller. If you are unsure which one that may be, you can download the Server 2003 Support Tools and run the NETDOM utility (from command line: "netdom query fsmo") to tell you which server is in fact the PDC. Once you have this information you log onto that server and check the registry settings as defined in this article. To save time and space I won't repeat everything that is in the article but here are some important points:
| • | All client desktop computers nominate the authenticating domain controller as their in-bound time partner. |
| • | All member servers follow the same process that client desktop computers follow. |
| • | All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner. |
| • | All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner. |
So this information seemed to check out and all the registry settings were there (see 'Configuring the Windows Time service to use an external source' in the above link) but I was still not able to get the updated time. After looking into the issue further and doing some 'Googling', I found that if you have your Windows Time Service configured in Group Policy and any GPO with this configured is being applied to the Primary Domain Controller, it simply will NOT work. Someone had this very thing configured in our Default Domain Controllers Policy and upon changing the settings to 'Not Configured' and updating the policy on the PDC (from command line: gpupdate /force) I was then able to sync the time without any issues.
When configuring an external time source for your domain always remember to:
-Check to see if any Group Policies with Windows Time Service settings enabled are being applied to the Domain Controllers, if so be sure to set them as Not Configured.
- Make sure you only have your Primary Domain Controller Emulator set as the 'NTP' server as mentioned in the above Microsoft article.
-Follow Microsoft's Best Practices when setting your refresh and correction intervals on the PDC.
If everything is hosed up and you want to start over, just use these commands:
net stop w32time
w32tm /unregister (this will wipe out all Windows Time settings)
w32tm /register
Configure your NTP settings in the Registry
net start w32time
w32tm /resync /rediscover
I happen to use tock.usno.navy.mil as my time server, if you want to check for more, I would recommend downloading and using a utility called NTP Query to test connections to time servers before going through the trouble of modifying your registry. It can be downloaded HERE.
Friday, June 29, 2007
70-290
Well, I passed my 290 exam today putting me on the road to MCSE with my shiny new Microsoft Certified Professional status. I'll have to admit, it was a lot harder than I thought it would be. I read the book from MS Press about 3 times and still didn't get all the details come test time. Does it matter now? Yes it does, the most important thing here is the material, not passing the test in my opinion. To me, you can cram for an exam and learn 'how' to take the test but do you really know the material? You have to be able to sustain yourself in the real world.
There were 'simulation' questions in which you took control of a desktop to do certain tasks. All in all, the questions were tricky. If you are going to take this test, you need to realize that it doesn't matter how YOU think you can accomplish a particular task, it matters how MICROSOFT WANTS you to perform the task. Of course there are different ways to get from point A to point B...but you have to think exactly the way they want you to and do it their way :-)
I think I'm going to work toward the 270 test (Windows XP) for my client cert, then it's on to the big baddies 291,293 & 294. I hear those are real boogers.
There were 'simulation' questions in which you took control of a desktop to do certain tasks. All in all, the questions were tricky. If you are going to take this test, you need to realize that it doesn't matter how YOU think you can accomplish a particular task, it matters how MICROSOFT WANTS you to perform the task. Of course there are different ways to get from point A to point B...but you have to think exactly the way they want you to and do it their way :-)
I think I'm going to work toward the 270 test (Windows XP) for my client cert, then it's on to the big baddies 291,293 & 294. I hear those are real boogers.
Friday, May 18, 2007
Adding drivers to a Windows PE Image
Supposing you have a server or machine with newer hardware that is not supported by default. You need drivers. Well there is hope without having to create a new image.
First you will need to disable the image in WDS and mount the image using ImageX. You must then figure out the image index of the image you wish to mount. This is usually a 1 or a 2. Open a command prompt,
type: imagex /info {imagepath/Imagename.wim}
Note the Index Number
then,
type: imagex /mountrw {imagepath/Imagename.wim} 2 {mountfolder}
Now you have your image mounted and can modify as needed. In the case of a specific driver you will need the .inf file as well as any tied to it. You will need to have the Windows Automated Installation Kit installed (preferably on your WDS box) and you will need to launch the Windows PE Tools Command Prompt which is already a shortcut in your start menu once AIK is installed. Once at the command prompt you will use the PEIMG command to load the driver.
Type: peimg /inf={path to driver} {image mount point}
(ex: peimg /inf=c:\broadcom\drivers\be086.inf c:\winpeimg\mount\)
Now you must unmount your image using ImageX and commit changes.
Type: imagex /unmount /commit {image mount point}
Re-enable your Image and restart the WDS service and you shouldn't have a problem. This worked in a case where I had a Dell PE2950 server with the new NetExtremeII TCP/OE network adapter which Windows 2003 does not have built-in drivers for. My problem was I could boot into the WinPE environment but got network driver error messages afterward. I used the above method to add the drivers to the image and the next time I tried it worked like a charm.
First you will need to disable the image in WDS and mount the image using ImageX. You must then figure out the image index of the image you wish to mount. This is usually a 1 or a 2. Open a command prompt,
type: imagex /info {imagepath/Imagename.wim}
Note the Index Number
then,
type: imagex /mountrw {imagepath/Imagename.wim} 2 {mountfolder}
Now you have your image mounted and can modify as needed. In the case of a specific driver you will need the .inf file as well as any tied to it. You will need to have the Windows Automated Installation Kit installed (preferably on your WDS box) and you will need to launch the Windows PE Tools Command Prompt which is already a shortcut in your start menu once AIK is installed. Once at the command prompt you will use the PEIMG command to load the driver.
Type: peimg /inf=
(ex: peimg /inf=c:\broadcom\drivers\be086.inf c:\winpeimg\mount\)
Now you must unmount your image using ImageX and commit changes.
Type: imagex /unmount /commit {image mount point}
Re-enable your Image and restart the WDS service and you shouldn't have a problem. This worked in a case where I had a Dell PE2950 server with the new NetExtremeII TCP/OE network adapter which Windows 2003 does not have built-in drivers for. My problem was I could boot into the WinPE environment but got network driver error messages afterward. I used the above method to add the drivers to the image and the next time I tried it worked like a charm.
Subscribe to:
Posts (Atom)