Springboard Series Virtual Roundtable Under the Hood: Windows Vista Performance...Need Answers?
Join Mark Russinovich and a panel of industry experts for a LIVE virtual roundtable to explore your top of mind performance issues, common misconfigurations, and tips on how to fix them. From boot times and applets to disk performance and battery life, find out how to optimize Windows Vista and what you can do to improve overall system performance.
Submit your performance questions live during the event or send them in advance to vrtable@microsoft.com. Save the date! Wednesday, September 24, 2008 9:00am Pacific Standard Time
Submit your performance questions live during the event or send them in advance to vrtable@microsoft.com.
Save the date! Wednesday, September 24, 2008 9:00am Pacific Standard Time
Find answers to your Windows Vista adoption questions with resources, tools, monthly straight-talk articles, and upfront guidance based on early adopter and community feedback. To learn more, visit www.microsoft.com/springboard.
Springboard Series: The resource for Windows desktop IT professionals
- Michael Platts
Hello all Networking Blog readers. My name is Brett Crane and I am an engineer with the Networking Teams here at Microsoft. I wanted to take a minute to show you a quick way to utilize Network Monitor to perform Sequential, or also called Circular, captures for troubleshooting issues. This is particularly useful when you can’t dictate when the networking communications you are looking for are going to happen. This method of troubleshooting has been available via GUI configurations using other network traffic capture utilities but has been, and currently is, only available through the command line options provided with Network Monitor.
(NMCap is a tool that is installed when you install Network Monitor 3.x. This is a command line based tool that provides great a bit of functionality. As time goes by you will find more postings on other uses this tool can provide.)
As said before, the goal of this discussion is to describe how to collect a sequential trace. What I mean by that is that you set Netmon to create a trace that only grows so large… 200MB for example. Once the capture has grown to 200MB it will close the current file and create a new one. That file will grow up to 200MB and then create another file. This will provide you the ability to go back and review your files and look to see if the date/time stamp matches the date/time of when your possible problem may have occurred. Having this information helps because you can delete the trace files that you know do not meet your criteria. If you were to just start a trace file and walk away it could easily fill your hard drive or become so large that it will become too much of a burden to be open or parsed in a timely fashion.
(Actual file size is adjustable and is dictated by the user entering the command. Based on your needs it could be 1500B or larger. The upper limit on the file size is 500MB. If you do not dictate a size it will default to 20MB. Please make sure you check available disk space as this process could easily fill your entire drive if not monitored properly.)
To utilize NMCap to collect the sequential captures you will need to install Network Monitor 3.x. (For download and installation information please look back at our other postings: http://blogs.technet.com/networking/archive/tags/Network+Monitor/default.aspx)
Once Network Monitor is installed, open a command prompt and use the following command line statement:
Statement Definitions:
NMCap: The application used to provide command line statements. It is a lighter weight application, takes fewer resources, and is more flexible.
/Network: Selects one or more space delimited network adapters to capture from. Adapters may be specified using their index, partial name with wild *, or quoted friendly name. (If you are uncertain of the Network adapters name you want to trace from you can find it using the NMCap /displayNetwork command)
/Capture: Saves frames that pass the frame filter to the specified capture files. Think of this as the start command for Network Monitor.
/File: The command after this switch will be what you are wanting to name the trace file. By following up this command with a “:” and a size, you will set the size in which each file will grow to be prior to stopping and starting the next file. Each new file will be noted by an incrementing number notation.
* Notes:
- In the example given above we used the file name test.chn. The extension chn stands for Chain. By using this extension in the filename we are telling NMCap to start the next file in the chain when we reach the stated size (200MB in the example). If you utilize the .cap extension in the filename of the format used above it will not create a new file. It will just cap off the file at the stated size then overwrite older data. By using the .cap file extension you will NOT accomplish the goal of multiple file creation!
- Keep in mind, as with all command line statements, the file will save in the current directory (e.g. from above: the file will be stored on the C:\ drive).
- There are many useful advanced filters that can also be used during the process of capturing Sequential/Circular Trace files (E.g.: /RecordFilters; /RecordConfig). For more information on commands of these sorts please refer to the Help for NMCap. (Help for NMCap can be accessed by running the following command in your CMD window: nmcap /?)
To stop your Capture process:
Once you feel the tracing has run long enough to capture what you are looking for, you will need to stop NMCap from continuing to create your trace files. To do this correctly all you will need to do is make sure that your Command Prompt window that you have opened and running the sequential traces on is the focus on your machine and hit Ctrl+C. Keep in mind that if you close the window you started tracing in, or log off, you will stop the tracing process.
*Note: There are advanced methods that can stop the tracing based on different variables such as Date/Time, for example. More information on these methods can be found in the Help for NMCap. (Help for NMCap can be accessed by running the following command in your CMD window: nmcap /?)
So, that’s all there is to it! Now you can let your traces run, checking back often and deleting the files that you know do not contain any relevant information!
(For more detailed information on using nmcap you can also refer to this link: http://blogs.technet.com/netmon/archive/2006/10/24/nmcap-the-easy-way-to-automate-capturing.aspx)
- Brett Crane
941091 The SnmpMgrOpen function fails and returns a null session, and the GetLastError function returns a 0 in Windows Server 2003
953317 A primary DNS zone file may not transfer to the secondary DNS servers in Windows Server 2008
936330 Information about Windows Vista Service Pack 1
935791 How to obtain the latest Windows Vista service pack
953733 MS08-047: Vulnerabilities in IPsec policy processing could allow information disclosure
Hi everyone,
Just in the last couple of days, I've heard that there's a new blog in town. It is just getting going at this point, but this could be a great one to check out as more details are released:
http://blogs.msdn.com/e7/
Now let’s look at a series of Bitsadmin commands used to create a BITS job and download a file. These commands are used to test the BITS client side and verify it works.
1. Create a download job called bitstest by typing the following in the directory where Bitsadmin resides:
Bitsadmin /create /download bitstest
2. Add the file you want to get and where to copy it to by typing the following:
Bitsadmin /addfile bitstest http://go.microsoft.com/fwlink/?LinkID=18922 c:\MSSecure.cab
3. Set your proxy settings to be the same as your IE settings:
Bitsadmin /setproxysettings bitstest preconfig
4. Check the job to make sure it's in a suspended state:
Bitsadmin /info bitstest /verbose
5. Set the job to go by typing:
Bitsadmin /resume bitstest
6. View the job again to make sure it’s in a state of Transferred:
7. To complete the job which will take the bits temp file and write it to the location you specified in step 2, type:
Bitsadmin /complete bitstest
Once you have completed these steps, you should see a file named MSSecure.cab in the root of the C: drive.
Listed below is an example of the commands described above being run on Windows Server 2008 using Bitsadmin 3 and the output from each command:
C:\Users\testuser>Bitsadmin /create /download bitstest BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. Created job {026C1A35-4608-4A54-AC31-2B632522BC7B}. C:\Users\testuser>Bitsadmin /addfile bitstest http://go.microsoft.com/fwlink/? LinkID=18922 c:\MSSecure.cab BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. Added http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab to job. C:\Users\testuser>Bitsadmin /setproxysettings bitstest preconfig BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. Proxy usage set to PRECONFIG. C:\Users\testuser>Bitsadmin /info bitstest /verbose BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. GUID: {026C1A35-4608-4A54-AC31-2B632522BC7B} DISPLAY: 'bitstest' TYPE: DOWNLOAD STATE: SUSPENDED OWNER: DOMAIN\testuser PRIORITY: NORMAL FILES: 0 / 1 BYTES: 0 / UNKNOWN CREATION TIME: 8/6/2008 6:16:19 PM MODIFICATION TIME: 8/6/2008 6:16:33 PM COMPLETION TIME: UNKNOWN ACL FLAGS: NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 3 RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 0 PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL DESCRIPTION: JOB FILES: 0 / UNKNOWN WORKING http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab NOTIFICATION COMMAND LINE: none Peercaching flags Enable download from peers :false Enable serving to peers :false CUSTOM HEADERS: NULL C:\Users\testuser>Bitsadmin /resume bitstest BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. Job resumed. C:\Users\testuser>Bitsadmin /info bitstest /verbose BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. GUID: {026C1A35-4608-4A54-AC31-2B632522BC7B} DISPLAY: 'bitstest' TYPE: DOWNLOAD STATE: TRANSFERRING OWNER: DOMAIN\testuser PRIORITY: NORMAL FILES: 0 / 1 BYTES: 68468 / 366823 CREATION TIME: 8/6/2008 6:16:19 PM MODIFICATION TIME: 8/6/2008 6:16:37 PM COMPLETION TIME: UNKNOWN ACL FLAGS: NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 3 RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 0 PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL DESCRIPTION: JOB FILES: 68468 / 366823 WORKING http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab NOTIFICATION COMMAND LINE: none Peercaching flags Enable download from peers :false Enable serving to peers :false CUSTOM HEADERS: NULL C:\Users\testuser>Bitsadmin /complete bitstest BITSADMIN version 3.0 [ 7.0.6001 ] BITS administration utility. (C) Copyright 2000-2006 Microsoft Corp. Job completed. C:\Users\testuser>
- Wayne Melvin
Introduction to the “Don’t be THAT guy” blog series:
I come in to work every day and get calls with these exact scenarios. Of course, the names have been changed to protect the innocent and to keep the guilty from having to find new jobs. The reason I wanted to start detailing some of these cases was to provide some cautionary tales for any one in the position of network or server administrator. Therefore, read this, what I hope to be the first of many blog entries, so that you might avoid being “THAT guy”.
Don’t be THAT guy… The case of the missing DNS zone.
The call came in from Scotland and apart from enjoying the gentlemen’s accents and their appreciation for a good pint I knew they had a pretty big problem. They described to me that the DNS zone for their company’s domain (corp1.local) was found to be empty after name resolution issues were reported. With their DNS servers being Active Directory integrated this meant that it was likely blank throughout their domain due to replication, and indeed it was. This is definitely in the “not good” category.
With all of their zone information gone an Authoritative Restore of the AD partition containing the DNS zone was going to be necessary. Once we started looking at this it was determined that the root cause of the problem was an Active Directory Object collision. This was collision brought about by someone at the company in a remote location (neither of my new Scottish friends) creating a 2003 server domain controller (DC) and installing DNS on it.
As you might have guessed all of the DNS servers are Active Directory integrated and store the zone information in AD. This means that all of the DNS records and zones are stored as objects within (AD). You can further specify where in AD you want these objects stored. You can choose to have them stored in the System partition (where Windows 2000 servers stored the info by default). Or, with Windows Server 2003 you can choose to store it in a domain-wide container (DomainDNSZones) or a forest-wide container (ForestDNSzones) depending on how you want the zone information deployed.
Now prior to the creation of this new DC and installation of DNS, all of their DNS servers (and by the way, to be AD integrated a DNS server must be a DC) were set to replicate to “All domain controllers in the Active Directory domain” as seen below:
Figure 1.
This configuration places all of the DNS zone information in the System partition of AD under the MicrosoftDNS container as shown below.
Figure 2.
Now when the customer’s technician (aka THAT guy) installed DNS they apparently did two things that are a BIG no-no. First after installing DNS he actually created the zone for the domain that he knew he would need. Now the first time people hear that they say “so…”, but after you think about how Active Directory Integration works with DNS you know this was a bad thing. Once this zone was created and left blank this “Change” was replicated out to all of the other DNS servers. Therefore, a blank zone for their domain was propagated through their environment effectively wiping out all current DNS zone information in its wake.
Now, admittedly the first mistake was probably the biggest since it can bring an entire network to its knees in one replication cycle, but the second mistake made it harder for us to correct the first one. When THAT guy was creating the new blank zone he accepted all of the 2003 Server DNS defaults which has the SECOND radio button (from figure 1 above) selected: “To all DNS servers in the Active Directory domain”. This forced the NEW zone that was created to be stored in the DomainDNSzones partition (See fig 3 below) and not the System partition like all of the other DC’s in the domain.
Figure 3.
Now I know what you’re thinking: If all of your other DC’s are using the System partition to replicate the DNS zones and that is also where there zone information is loaded from, then WHY would these DC’s load the “blank” zone from the DomainDNSzones partition? I’m glad you asked because I did the same thing. When we looked at the System partitions on the DC’s we found that all of the correct zone information was there and had not been overwritten by the “blank” zone. Why did it not load into DNS?
When the new zone replicated to the DomainDNSZones partition this created a duplicate object for the corp1.local zone within AD that in turn caused a collision. This collision or conflict within AD kept the good zone data from being loaded. Once we determined that the empty zone existed in DomainDNSzones we simply deleted it and restarted the DNS service on the DCs to restore the proper zone info and name resolution was restored throughout their network.
So what could have prevented this poor soul from becoming THAT guy? Here are some possibilities:
1 – Having a test domain with either physical or virtual machines set up to mimic your corporate environment so upcoming changes can be demonstrated as safe. Even condensing a world wide environment to a handful of VM’s is better that shooting from the hip.
2 – Having a change control process where the changes to be made are reviewed before granting permission for they implemented.
3 – Having your buddy look over your shoulder and give you a reality check before you press “OK”.
If you would like to know more about the DNS scenario that took place above please follow the link below:
867464 Event ID 4515 is logged in the DNS Server log in Windows Server 2003
And remember: Don’t be THAT guy.
- Steven Martin