• AIX: iptrace: /usr/sbin/iptrace [ -a ] [ -b ][ -e ] [ -u ] [ -PProtocol_list ] [ -iInterface ] [ -pPort_list ] [ -sHost [ -b ] ] [ -dHost ] [ -L Log_size ] [ -B ] [ -T ] [ -S snap_length] LogFile
• FreeBSD: tcpdump (I think): tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ] [ -C file_size ] [ -F file ] [ -i interface ] [ -m module ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -E algo:secret ] [ expression ]
• HP-UX: nettl: nettl requires a daemon start, and other setup: /usr/sbin/nettl -traceon kind… -entity subsystem… [-card dev_name…] [-file tracename] [-m bytes] [-size portsize] [-tracemax maxsize] [-n num_files] [-mem init_mem [max_mem]] [-bind cpu_id] [-timer timer_value]
• Linux 2.4 and higher:
  • tcpdump (some distros): tcpdump [ -AdDefKlLnNOpqRStuUvxX ] [ -c count ] [ -C file_size ] [ -G rotate_seconds ] [ -F file ] [ -i interface ] [ -m module ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -E spi@ipaddr algo:secret,… ] [ -y datalinktype ] [ -z postrotate-command ] [ -Z user ] [ expression ]
  • wireshark (some distros, used to be called “ethereal”): GUI-config, no command-line, use tethereal for that
• Mac OSX: tcpdump (among others): tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ] [ -C file_size ] [ -F file ] [ -i interface ] [ -m module ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -E algo:secret ] [ expression ]
• Solaris: snoop: snoop [ -aPDSvVNC ] [ -d device ] [ -s snaplen ] [ -c maxcount ] [ -i filename ] [ -o filename ] [ -n filename ] [ -t [ r | a | d ] ] [ -p first [ , last ] ] [ -x offset [ , length ] ] [ expression ]
• Windows 2000, XP, 2003, Vista, 2008 and beyond: netmon (not installed by default): GUI config, filter creation info here

Any others anyone wants added (or corrected), just comment or email and I’ll update this.
(Edit 7/29/08 - change tcpdump link)

Apperantly Solaris 10 and OpenSolaris have a little quirk around how they work with DHCP and setting the system’s DNS name. In our test lab, all our systems are assigned addresses via Microsoft DHCP, which then registers (and un-registers) non-Windows systems in DNS properly. However, the x86 Solaris systems we built for a customer test came up with name “unknown”, every single reboot. Changing /etc/hosts and /etc/hostname.pcn0 or /etc/hostname.vmxnet0 (physical or VMWare) to reflect the new proper hostname, however, didn’t affect the server on reboot - the settings would still be there, but not reflected in the OS, in /etc/hosts, or in DNS.

A bit of searching turns out a bunch of posts talking about editing /etc/nodename to put in the system name, but that file doesn’t exist out of the box on a “complete” or “minimal” install, and I’m always hesitant to create new files by hand in /etc/ unless I’m 100% sure that’s what’s needed. According to this post on Sun.com, some logic, and some testing, I think what’s going on is:

1. Solaris expects DHCP to set the hostname of a system based on MAC address
2. In case DHCP does not set a hostname via MAC address, or if that hostname is wrong, Solaris provides an override mechanism called /etc/nodename
3. Because it’s an override, /etc/nodename is not created as a blank file, since that could be construed as “override DHCP with nothing”
4. Therefore, every new box I build needs touching after final login

I’m not a huge fan of this, but I’m also not a fan of the number of times I need to click a mouse on an OS Install using software from the last year. The short version of all this is:

If you have a Solaris 10 box on DHCP named “unknown”, best practices is to set the hostname on the DHCP server. Otherwise echo newservername > tee /etc/nodename and reboot. (with “tee” in the pipeline, you can “sudo” this command as well).

1. Guy Teverovsky (Microsoft MVP) has created the CoreConfigurator which gives a small GUI to many of the initial setup pieces of Server Core, so you don’t have to follow my detailed (cryptic) instructions.
2. Create Shadow Copies on your Server Core file server with
   vssadmin add shadowstorage /for=C: /on=D: /maxsize=900MB
vssadmin create shadow
at 7:00am /every:M,T,W,Th,F,S,Su "vssadmin create shadow /for=c:"

   MaxSize can be bytes (/maxsize=10240), KB, MB, GB, TB, PB, or EB (/MaxSize=1EB), assuming your disk is that big.

I haven’t used CoreConfigurator myself, but I did create my shadow copies again finally on our main server today. There’s a backup that’s amazingly great to have.

Edit on July 8, 2008:  I forgot the”/for=c:” in my paste back to here -I was configuring another Windows Server 2008 Server Core file server and couldn’t figure out why the scheduled task wasn’t creating shadow copies properly.  Sorry to anyone who used this note and had issues.

1. The guide mentions “Join the new server to the domain” as part of the DCPromo process. I like to separate this out as a way of verifying the join goes well, and that the server can get fully patched more easily. There is a 7 day limit to having 2 SBS 2003 servers live on the network at the same time, and it’s enforced by the old server shutting down after 1 hour uptime. However, this limit isn’t enforced untill after you run the second part of the SBS setup (the first part is the OS setup, the 2nd is the Windows mode “double-click to run” setup). This gives you time to patch and prepare the OS prior to that time limit starting.
2. Once the 2nd part of setup has been run, migrate your users immediately.
3. Migrating users includes moving their mapped drives to the new server. The Client Side Caching Tool from Microsoft will make this much easier. I normally do this change as follows:
   1. Create the share on the new server, if you’re not using the default SBS \Users share.
   2. Edit all user’s profiles to point to the new location. I’ll post a script for this later, but all of the ones I have at this time are protected by IP contracts, and therefore non-sharable. I believe there’s at least a stub for this at either Don Jones’ Scripting Answers or Microsoft’s Script Center.
   3. I have yet to see an SBS environment with no laptops. Therefore, you’ll want to move the Client Side Cache for the My Documents of your users.
      1. Copy csccmd.exe to your NetLogon share on your DC (c:\WINDOWS\SYSVOL\sysvol\domain.local\scripts by default)
      2. Find the current path, and new path (\\dc01\Users for current, and \\dc02\Users for new, below)
      3. Make the logon script be: “\\domain.local\netlogon\csccmd.exe /moveshare:\\dc01\Users \\dc02\Users”
      4. When all the laptop users have logged in and run this script, unlink the GPO but keep it around for documentation (knowing how documentation is in most Small Businesses I’ve visited). This will speed up logons for everyone.
4. Now you can finish the Exchange / SharePoint / ISA setup. This will require downtime, but is easy to do, if you’re following the document referenced above.
5. Finish up cleanup of Exchange prior to the 7 day timeout value. you’ll need to replicate all the Public Folders, OAB, and Free/Busy data as documented in the “Migrating to new Hardware” document.
6. Uninstall Exchange on the original server.
   1. Requires “Modify”ing the Small Business Server roll in “Add/Remove” programs. choose to uninstall Exchange.
   2. This cleans up a huge number of items in AD, and makes future migrations simple. Also cleans up potential problems down the road.
7. DCPromo the original DC, so it’s not a DC on the original network. Just run “dcpromo” and remove the server from being a DC.
8. Now you can shut down the old DC and have no issues.

However, if you follow my guide directly, you’ll run into a single issue: https://servername/oma (or Exchange ActiveSync) will fail with an error: Server Error in '/OMA' Application.
Collection was modified; enumeration operation may not execute. You will only see this error if you try to access the site directly from the new SBS2003 server. Remotely, you’ll just get a generic error.

This is caused by .NET Framework 2.0 being installed *prior* to Exchange 2003. If you join the domain with the DCPromo and do patching *after* the fact, this probably won’t come up, because .NET Framework 2.0 won’t install untill after Exchange 2003 is installed. If, however, Exchange 2003 is installed first, you’ll probably get this error.

Good news, it’s a simple fix:
c:
cd\windows\Microsoft.Net\Framework\v1.1.4322\
aspnet_regiis -sn W3SVC/1/ROOT/OMA/
iisreset /restart

It might take 2 minutes to initialize, but OMA and ActiveSync should now work flawlessly.  As is always implied, contact us somehow if you have issues!

FIrst, you have to install the server and set an IP address - my previous posts on IP changes on DCs all used netsh commands as well, so if you followed thouse, you should be somewhat prepared for Server Core. I already had a WIndows Server 2003 DC in the environment, so that will be my primary DNS server for the install, untill DCPromo edits the settings.
netsh interface ipv4 set address local static 10.1.1.6 255.255.255.0 10.1.1.1 10
netsh interface ipv4 set dns local static 10.1.1.5
netsh interface ipv4 set wins local static 10.1.1.5

Now networking is set up, we can rename the computer: netdom renamecomputer %computername% /NewName:dc02 and join the domain with netdom join dc02 /domain:foo.local /UserD:FOO\Administrator /reboot:5 /PasswordD:*. The “5″ after the reboot flag says to reboot 5 seconds after completion, and the “*” at the end says to prompt you for your password. I join the system to the domain manually first, because then I can WSUS patch it (if WSUS is in the network), or open up the firewall for any other patching software I have.

Once the server is back from reboot, activate, update the firewall to allow remote MMC connections (if you’re not doing that through GPO already), and install new roles.
slmgr.vbs -ato
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

The following roles are optional, depending on the service of the server. Mine has DNS and the File Server roles, but not DHCP. None of these are required to install AD Domain Services!
start /w ocsetup DNS-Server-Core-Role
start /w ocsetup DHCPServerCore
start /w ocsetup FRS-Infrastructure
start /w ocsetup DFSN-Server
start /w ocsetup DFSR-Infrastructure-ServerEdition

If this is the first Windows Server 2008 DC in your environment, you’ll need to take the Windows Server 2008 DVD to the DC with the Infrastructure Master role (required for /gpprep only) and run the following (E: assumed as DVD-ROM drive):
e:\sources\adprep\adprep.exe /forestprep
e:\sources\adprep\adprep.exe /domainprep
e:\sources\adprep\adprep.exe /domainprep /gpprep (Also run adprep /rodcPrep if you plan on building RODCs.)

Now you’re ready to do the DCPromo itself. Create an unattend.txt file. To add a DC to an existing domain, you can use:
[DCInstall]
AutoConfigDNS=Yes
ConfirmGc=Yes
DatabasePath=E:\Windows\NTDS
LogPath=c:\windows\NTDS
RebootOnSuccess=Yes
ReplicaDomainDNSName=foo.local
ReplicaOrNewDomain=Replica
ReplicationSourceDC=dc01.foo.local
SafeModeAdminPassword=passwordhere
SysVolPath=e:\windows\SysVol
UserDomain=foo.local
/Password:passwordhere

DCPromo will wipe out the passwords when it starts, or you can fill in “*” instead of the password, to be prompted. When it’s done, the server will reboot and be a new Global Catalog / DC in your domain. DCPromo will install neccessary binaries and configure the firewall for DC Services for you. It’s quite slick.

And as promised, here are the DCPromo Unattend Options for reference for creating your own unattend.txt.

Don Jones had the next session, but I had to skip out on it to prepare for my session. I did hear some great feedback, but was disappointed, since his was one of the sessions I was most looking forward to prior to the conference start.

I spoke at 11am about how to integrate Linux/Unix systems with Active Directory. Download the deck here. It was a great experience, and the bit of feedback I’ve heard so far has been really positive.  It sounds like several attendees have moved their integration projects forward with information I presented, so I think it was successful.

After lunch, the Microsoft Windows and Active Directory product teams had a chalk talk about what’s next with AD where they solicited a LOT of suggestions from the attendees.  I was surprised by the number of people who are using “Prune and Graft” techniques for domain migrations.  Microsoft was very clear, however: do not EVER prune and graft domains.

And I’ll leave it at that.  In all, in was a great experience, and I learned so much.  I’m going to go back again!

Sunday March 2nd was only registration and the reception for me. I just used the brief time downtown to meet with the Centrify and Likewise teams who worked so hard over the previous month to help me prepare my presentation for Wednesday. I met a bunch of great new contacts as well - not a conversation passed that I didn’t learn something new.

Monday the 3rd included Gil Kirkpatrick’s discussion on AD administrators vs. software developers, Jerry Camel and Brad Turner’s overview of proper architecture for ILM “2″, how Microsoft is using Windows Server 2008 (Brian Puhl), an amazingly indepth look into AD with Dean Wells and Joe Richards, and a discussion about how Centrify DirectControl works (in Centrify’s vendor track). (more…)