THE OFFICIAL BLOG OF THE SBS DIVA

I'm tweaking auditing and alerting again.

I like... okay no I LOVE it when I get an alert when someone fails to log into the server. Why?  Because I want to know who's banging on my ports.  But at the same time I don't want to be so overloaded with alerts that I can't stand it.

So I use my Calyptix Firewall to limit my SMTP email to those IP addresses that are from Exchange Defender.  Then I limit RDP to either only be accessed via VPN or limit it to my external Static IP. 

How can you do this you ask?  Easy with SBS 2008.  Not so easy with SBS 2003.  With 2k3 you need an external firewall that can handle this.

With SBS 2008 you can do this by adjusting the inbound RDP to only be allowed from the internal IP addresses of the network AND the internal IP addresses from your remote session.

Now we go and adjust the default domain controllers policy to track our failures and not just our successes.

Add failure to those audit events so that you get those alerts.

Then right mouse click on the audit event log and kick up the size.  The default is 16384 KB which is fine for some of the other logs but small on the audit ones.

I also kick up the default auditing policy to log FAILURES.  I don't want to see just the successes, I want to see the attempts to get in before they are successful.

And while I had stuck in Philip Elder's alert from the www.codeplex.com/sbs

 The resulting alert looks like this:

An alert was detected on your network. Further investigation into the issue is recommended.

Computer: SERVER
Date/Time generated: 11/30/2009 11:05:12 PM
Title: Failed User Logon
Source: Server
Description: 
An account failed to log on.

Subject:
 Security ID:  S-1-5-20
 Account Name:  SERVER$
 Account Domain:  DOMAIN
 Logon ID:  0x3e4

Logon Type:   3

Account For Which Logon Failed:
 Security ID:  S-1-0-0
 Account Name:  Someone
 Account Domain:  

Failure Information:
 Failure Reason:  Unknown user name or bad password.
 Status:   0xc000006d
 Sub Status:  0xc000006a

Process Information:
 Caller Process ID: 0x4c0
 Caller Process Name: C:\Windows\System32\inetsrv\w3wp.exe

Network Information:
 Workstation Name: SERVER
 Source Network Address: -
 Source Port:  -

Detailed Authentication Information:
 Logon Process:  Advapi  
 Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 Transited Services: -
 Package Name (NTLM only): -
 Key Length:  0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
 - Transited services indicate which intermediate services have participated in this logon request.
 - Package name indicates which sub-protocol was used among the NTLM protocols.
 - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

I'm not saying that there isn't historical issues with the black screen of death (aka KSOD) that Mark Crall probably lost a few dents in his head to a few months back, but tonight as the Techmeme articles are parroting the "Latest Microsoft Patches cause black screen of death", I'm asking ...okay are all of the folks supposedly impacted by this not calling in, not posting in a newsgroup, not posting in a forum and only silently suffering? 

I will be the first to eat crow (rather than leftover turkey) if something comes out of this, but right now I'm doubting Thomas for sure.

Microsoft investigates Windows 'black screen of death' triggered by recent security updates | Security - InfoWorld:
http://www.infoworld.com/t/security/microsoft-investigates-windows-black-screen-death-triggered-recent-security-updates-424

"Searches of Microsoft's support forums today, for example, turned up only one "black screen" thread with posts after the Nov. 10 security updates had been released. Four different users on that Windows 7-specific thread said that they faced a blank screen."

Microsoft investigating 'black screen of death' | Beyond Binary - CNET News:
http://news.cnet.com/8301-13860_3-10406369-56.html

"So this is a problem that ostensibly would have happened 20 days ago? Does it happen right away, or under certain circumstances.

Cause if its supposed to happen right away, I'm sure we would have heard about it before a press release from a software vendor. People love to jump on any problems that MS has, I'm surprised it would have stayed quiet for 3 weeks."

"I loved this line from the link "If you Google Black Screen then you will find a whopping 80Million plus results" except all but the computer world article and Cnet article are between 1 and 5 years old."

So if some of your workstations are not showing up properly in the SBS 2008 Computers console, here's what I did to fix all of my truant ones.

Event ID 10016 Source DCOM:
http://www.eventid.net/display.asp?eventid=10016&eventno=4718&source=DCOM&phase=1

In my case I went into Dcomcnfg.exe

Then I went under component services, computers, my computer, dcom config, then found the 49BD2028-1523-11D1-AD79-00C04FD8FDFF CSLID and changed the settings to "use default"

Rebooted.

Then I followed this and

Repairing and re-registering the WMI:
http://windowsxp.mvps.org/repairwmi.htm

Did the following commands at a c:\

rundll32 wbemupgd, UpgradeRepository

Then did this:

This big square box will load up just hit cancel.

Close the command window.

Why did I do all of that?  to get the WMI kicked back into gear so I could fix the lack of security status being reported in the SBS 2008 console.

If your machines are not checking in, it's either a firewall blocking the communication, or your WMI messed up.

Vista and Win7's were connecting just fine but I had three XPs not reporting the proper security status.   Remember that servers will not report a status as they have no security status center.

And now I'm not .....

Now protecting the RWW access (especially for the administrator account)...

And the cool thing is that I can now use iPhones and Windows mobile phones to be portable softtokens

I've also added the protection to the RDP access to the server so that it's not open.  Mind you I already limited the RDP access to certain IP addresses, but this tightens up security that much more.

And you can extend the password policy and let people change them LESS often to then ensure that they choose better passwords.

Windows Small Business Server 2008 from SBS 2003 R2 | Loz's ALITs Blog:
http://www.alits.co.uk/WP/?p=158

For the migration scenario from Windows Small Business Server 2003 R2 to Windows Small Business Server 2008, a manual migration will be required. More information will be provided in the future.

"Exactly who’s future is that then? Do we have to wait for an R2 release of 2008 to be able to do a slick automation of the upgrade process? All very foggy - but we shouldn’t really be surprised!"

Two comments to this post. 

We will never have a slick automation of the upgrade process.  There is too much in active directory.  Not to mention going from SBS 2003 to SBS 2008 it's a 32 to 64 bit transition.

And If there ever was the ability to have a slick upgrade process, that kinda means IT pros are no longer needed?  :-)

Seriously, that page needs a little bit of updating as the migration docs have been published.

http://blogs.msdn.com/sbsdocsteam/archive/2009/11/12/the-windows-sbs-2008-migration-guides-are-updated.aspx

And if you are looking for other alternatives... www.sbsmigration.com provides support along the way.

But automatic?  Not possible with the kind of networks we have.

So when you put another server on the network and just set it up for a specific purpose it may not open up all of the needed protocols in the firewall that it needs to correspond to the SBS 2008 box.

So here's how to adjust the firewall to get the Dcom messages out of your event logs:

Event ID 10009 Source DCOM:
http://www.eventid.net/display.asp?eventid=10009&eventno=579&source=DCOM&phase=1

 

Check the firewall settings and enable the firewall exception rule

To check the firewall settings and enable the firewall exception rule:

1. Click Start, and then click Run.
2. Type wf.msc, and then click OK. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
3. In the console tree, click Inbound rules.
4. In the list of firewall exception rules, look for COM+ Network Access (DCOM In).
5. If the firewall exception rule is not enabled, in the details pane click Enable rule, and then scroll horizontally to confirm that the protocol is TCP and the LocalPort is 135. Close Windows Firewall with Advanced Security
6. 

Right mouse click and enable the rule

Then to get the server to be able to query the name/model of the remote server enable the WMI in the inbound firewall rules as well.

Once you do that your server will report into the console and provide the hardware information on the Network/Computers tab.

When you set up ANY computer, be it a workstation, server, whatever, you want to flip from Windows Update to Microsoft Update.

In Windows 2008/Vista/Windows 7 there's a tiny little section you need to click on to get it to flip.

Which then brings up the web page to opt into Microsoft update.

Even though the server is patched by WSUS, this way you can run manual scans to MU as you like.

When you add a member server to your SBS 2008 you will notice that it adds itself as a workstation.

You have to go into active directory users and computers, find the MyBusiness OU, then go to the SBSComputers OU and move the Server that's listed in the SBS computer section over to the SBSServers section.

Right click on the name of the server, and click on move.

Then MOVE the server to the right OU so that it's listed up in the right section in the networking console.

And the fact that the security status is "Not available" is normal.  There is no security status center on a server.

So "normal" for servers is green/grey/green/green.

Ever go into a new place and don't know what the password is for a device like a printer or something like that?

Default passwords list - Select manufacturer:
http://www.default-password.info/

Look for them on that web site.

One of the key "this will nail you EVERY migration you attempt" is the Journal Wrap.  And I've seen a lot of folks in the SBS world with a journal wrap error.

Fortunately it's an easy fix.  You literally read the KB article that it points to and voila, it fixes the journal wrap error.

This was an old one I had years ago on my old SBS 2k3 server.  I got in this condition because I didn't have a good UPS on the home server and Dad and PG&E shut down the circuit breaker on the house during Thanksgiving weekend in 2007.  I didn't fix the error until Christmas because on a single domain box, you won't notice it having issues.

Event Type: Error
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date:  12/25/2007
Time:  2:43:19 PM
User:  N/A
Computer: KIKIBITZFINAL
Description:
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
 
 Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
 Replica root path is   : "c:\windows\sysvol\domain"
 Replica root volume is : "\\.\C:"
 A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons.
 
 [1] Volume "\\.\C:" has been formatted.
 [2] The NTFS USN journal on volume "\\.\C:" has been deleted.
 [3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
 [4] File Replication Service was not running on this computer for a long time.
 [5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
 Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
 [1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
 [2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
 
WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.
 
To change this registry parameter, run regedit.
 
Click on Start, Run and type regedit.
 
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
   "System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
   "Enable Journal Wrap Automatic Restore"
and update the value.   [to 1]
 
If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Keep in mind that even if you have fixed it, it may still show up in the BPA report as it sees that old journal wrap event left over in your File replication log files.  The key thing is to review the File replication log and ensure that post registry you get indicators that the system has been fixed up.

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13560
Date:  12/26/2007
Time:  12:34:03 AM
User:  N/A
Computer: KIKIBITZFINAL
Description:
The File Replication Service is deleting this computer from the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" as an attempt to recover from the error state,
 Error status = FrsErrorSuccess
 At the next poll, which will occur in 5 minutes, this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13520
Date:  12/26/2007
Time:  12:39:39 AM
User:  N/A
Computer: KIKIBITZFINAL
Description:
The File Replication Service moved the preexisting files in c:\windows\sysvol\domain to c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.
 
The File Replication Service may delete the files in c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog at any time. Files can be saved from deletion by copying them out of c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog. Copying the files into c:\windows\sysvol\domain may lead to name conflicts if the files already exist on some other replicating partner.
 
In some cases, the File Replication Service may copy a file from c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog into c:\windows\sysvol\domain instead of replicating the file from some other replicating partner.
 
Space can be recovered at any time by deleting the files in c:\windows\sysvol\domain\NtFrs_PreExisting___See_EventLog.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Information
Event Source: NtFrs
Event Category: None
Event ID: 13553
Date:  12/26/2007
Time:  12:39:40 AM
User:  N/A
Computer: KIKIBITZFINAL
Description:
The File Replication Service successfully added this computer to the following replica set:
    "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
 
Information related to this event is shown below:
Computer DNS name is "kikibitzfinal.Kikibitzrtm.local"
Replica set member name is "KIKIBITZFINAL"
Replica set root path is "c:\windows\sysvol\domain"
Replica staging directory path is "c:\windows\sysvol\staging\domain"
Replica working directory path is "c:\windows\ntfrs\jet"

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Using the BurFlags registry key to reinitialize File Replication Service replica sets:
http://support.microsoft.com/kb/290762

Complications from an SBS 2008 Migration :: Third Tier:
http://www.thirdtier.net/2009/11/complications-from-an-sbs-2008-migration/

And don't blow off what it says....

One of the group policy tweakages I've done is to have it so that when someone connects via RWW that the desktop background they have on their office machines get's blanked out.  With Vista and Win7 and the nice (heavy graphical) wallpapers people have chosen slows down the remote web workplace screen.

So just go into Group policy

and enable the "Enforce Removal of Remote Desktop Wallpaper"

How Autodisconnect Works in Windows NT and Windows 2000:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;138365
Mapped Drive Connection to Network Share May Be Lost:
http://support.microsoft.com/kb/297684
Mapped drive shows an X - Super User:
http://superuser.com/questions/42072/mapped-drive-shows-an-x

One of the visually annoying things in the WinNT stack is how mapped drives "fall off" the network with red X's but they don't really fall off.

So how can you get rid of this slight visual annoyance? 

A registry key I've stuck on all my servers that have mapped drives.

At the command prompt with the following command:  net config server /autodisconnect:-1

Or

HKEY_LOCAL_MACHINE under the subkey:

Of interest is that this patch stopped the TS Gateway service

Thus dropping the RWW session.

Once again proving that you can't consistently patch over a RWW session and you need some other methodology to patch.

It may be Thanksgiving in the USA but we're also getting ready for Christmas as the Bradley/Mini Cooper family.

My sister has planned the Antenna ball toppers AND the car magnets for the count down to Christmas...

Yes, that's an analog calendar but it's a MINI COOPER analog calendar from the North American Motoring forum mind you.

In black  ink are the reminders of what Antenna balls we are to put on our cars, in Red ink is the reminder for the magnets.

[We are a little scary, aren't we?]

Happy Holidays everyone!

One of the things I added to David Overton's robocopy script to copy and move permissions from one server to the other is this extra flag:

/DCOPY:T

What it does is copy over and leave intact the date time stamps on the copied over folders.  So that rather than stamping them all the date of the migration (which is what I did last time nearly five years to the date), this time I'm maintaining the date stamp info.

I also added an A to the /COPY:DATSOU

D = copy the data

A = copy the attributed

T = Copy the timestamps on the individual files

S = Copy the securtiy ACLs

O = Copy the ownership info

U = Copy the Auditing info

Don't forget that once you've migrated the mailboxes, any special permissions you had (send on behalf for blackberries for example) were not migrated over.

Now sit down because I'm going to blog about something that every single time I say this to someone they absolutely freak out.

We have a written policy in our office that the firm email IS the firm email.  Thus every piece of electronic email that comes in and goes out using the firm's Outlook has the right to be read, inspected, reviewed, etc.  Now if that wasn't enough we take it one step farther.  We give everyone (yes you read that right EVERYONE) in the office the ability to access everyone else's email and calendars.  There is no expectation of privacy on the firm Outlook.  You want to keep something private, go use gmail during your lunch hour or use the personal email on your smartphone. 

How to Allow Mailbox Access: Exchange 2007 Help:
http://technet.microsoft.com/en-us/library/aa996343.aspx

So I go into folks' email boxes and set Manage Full Access Permission to be open to everyone else.  Why?  Because as a small firm that works with Attorneys that have deadlines of yesterday, sometimes you get the "Go into my email and ..." over the phone.  And even with iPhones, the screen isn't big enough sometimes for such items or ... let's face it... the end user isn't as geeky as the rest and so to be collaborative of a firm that we need to be, we give full access.

But Susan, what about the expectation of privacy?

We put it front and center in our company policy.  It's our computer equipment, it's our Outlook.

But Susan, but...but....

But what?  Where in the law book of dealing with employees do they say that there is an expectation of privacy in firm email?  We lay it out front and center.  You don't have any.  Period.  Furthermore we back it up with permissions.

But what about security and sensitivity of the mailboxes?

Email isn't secure.  We have secure folders on the server that keep Human Resource documents, and anything of that sensitivity we don't email.  Again, lay down the rules, set a policy, here's what will be considered private, here's what isn't.  It's that simple.

You still can set individual rights like this at the server per person, or you can go into the user's specific mailbox and have that user grant rights to the other person (like when you delagate send on behalf rights to another person.

Long story short, I got to the final mailbox and it got interrupted. 

Great.  Okay don't panic.  We know if a mailbox doesn't move we can go back in and restart it.  So we do that.  and......

Error occurred in the step: Preparing mailbox to be moved. Failed to copy basic mailbox information with error: A duplicate mailbox was found due to problems during a Move Mailbox procedure. The duplicate mailbox has been deleted. Try again later

Rats. 

Okay ...hmm that said it deleted the duplicate mailbox so let's go back into the move mailbox again and try it again.

Error occurred in the step: Preparing mailbox to be moved. Failed to copy basic mailbox information with error: After moving a mailbox, you must wait for cleanup operations to complete before you can move it again

Rats again.  Okay... hmmm is there a way to kick that cleanup operations faster?  As it only runs once a day and I don't plan to be here all night.

Yes there is... open up the Exchange powershell command and type in clean-mailboxdatabase then enter the name of the database "Mailbox Database"

Clean-MailboxDatabase: Exchange 2007 Help:
http://technet.microsoft.com/en-us/library/bb124076.aspx

Voila it kicks a clean up and then you can resume moving over that one mailbox that barfed on ya.

1) For moves within the site (ie - the moves that you've always been able to do), or for moves between sites when you're in Exchange 200x native mode, you do NOT need to do anything with the Outlook profile. Outlook will attempt to connect to the original server the next time you start Outlook and will be automatically redirected to the proper server.

Migration Grunt -

When you login to the mailbox after the mailbox has been moved, you will make a connection to the original mailbox server (presuming this server is still up and running). This server will "know" that the mailbox has been moved (because it can consult the directory and see the updated HomeMDB/HomeMTA). The original server will then "tell" the Outlook client "hey, you're on SERVER-X now" and Outlook will update its profile to reflect this automatically.

So, in short, sure there are things that can break this process. But so long as the original server is still up and running, and so long as the directory is updated and replicating properly, this process should be quite automatic.

You Had Me At EHLO... : How does move mailbox really work?:
http://msexchangeteam.com/archive/2005/02/15/373021.aspx

Somewhere buried in the documentation I've read is this gem... when you are in the process of "Move mailboxes" the client/Outlook has to close and reopen one time once the mail has been moved over.

Once that runs and says it's successful, you need to have the users close and reopen their Outlook.  As was pointed out by Axel Larson, this is obviously going to work the best while that SBS 2003 is still up.  So ... what's a gal to do on a Thanksgiving weekend when everyone has left and you want to ensure the boss's email account works?

You reset his password is what you do and log into his workstation/profile and make sure it works.  For people that you aren't as nice to (let's be realistic here) you keep the box up until past Monday morning. 

But the way to check is close and reopen Outlook.  It should now point to the new server in the exchange server settings under the hood.

With the content that I've blogged so far... and if I do any more specifically on point I'll update it ... here's the recap of all of the Migration related blog posts

http://cid-c756c44362cd94ad.skydrive.live.com/browse.aspx/SBS%202008%20migration

I still have topics to go such as encryption and comparison of the methodologies out in the marketplace.  Plus I might go back through and clean up some of that narrative a bit.

Just remember over the holidays that the SBS 2008 newsgroups will be open for business as they always are.

http://www.microsoft.com/sbs/en/us/forums-blogs.aspx

So if you need help or want to do a dry run this American holiday weekend, we'll keep the lights on for ya.

If you are seeing 931125 being reoffered via WSUS it's due to the fact that the May 2009 update is not properly marked at "HasSupercedingUpdates" which is messing up the offering of the September update causing it to be reoffered.  Decline both the Feb and May 2009 update in WSUS.

Then on the workstation if you are getting it still reoffered you have to clear it out of the software distribution folder.

Per Chuck on the SBS2k list -- To recap the fix for others.

1. Went to WSUS and manually declined both of the updates.
2. Stopped the Automatic update service on the affected workstations.
3. Deleted everything in C:\WINDOWS\SoftwareDistribution.
4. Restarted the automatic update service.
5. Restarted the work stations.

(edit ... you can also delete out just the cert folder under that softwaredistribution folder and just chuck that out the door)