Sunday, May 11, 2008

ShadowProtect, Exchange Logs and special note on SBS exchange VSS

 
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Friday, May 9, 2008

Quick note on BES database installs

 So, in order to get the BES installation working on SBS, you should create a new instance of MSDE before ruining the installation. You can do this as follows:

1. Locate the MSDE files on the SBS 2003 CD 3 or download from Microsoft.

2. Open a command prompt (Start -> Run -> cmd -> clickOK).

3. On the Command Prompt, change to the directory where the MSDE files are located e.g. cd D:\SBS\MONITOR\MSDE

4. Enter the following command to create the new instance:

setup INSTANCENAME=”BESMgmt” SAPWD=”AStrongSAPwd” /L*v C:\MSDELog.log

5. Start the service: Start -> Run -> Services.msc -> Click OK. Scroll down to the instance you just created MSSQL$BESMGMT, select and click start service.

6. Check the log file to make sure everything installed correctly at C:\MSDELog.log

Then when you run the BES installation, simply enter BESMgmt as the database name. The installation will then run like a dream.

 

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Monday, May 5, 2008

Another BES MSDE tip

Choosing a remote server install using a format of SBSServernsame\BESMgmt seems to create the necessary database (even though I already had created named instance)
 
May be worth trying in production.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

An alternative means of using Blackberry with SBS

"Alternatively, you can set up Exchange to forward a copy of email to an address assigned to the Blackberry.  To do this, first create an email address for the Blackberry, usually through your provider's Blackberry website.  It will be in the format "username@vzw.blackberry.net".  Make sure the return address is set to the user's primary email address, not the Blackberry email address.  Next, on your SBS server, create a new Contact under Advanced Management->Active Directory Users->[Your Domain].local->My Business->Users->SBSUsers.  Fill in the name with something like "UserA's Blackberry".  On the second page, select the Modify button and choose "SMTP" address.  Fill in the Blackberry address here, then complete the wizard.  You should see the contact listed now.  Select the corresponding user and go to properties.  Under Exchange General, press the Delivery Options button.  There, you can set it to forward to the contact you just created.  Make sure you check the box to deliver to both the forwarding address and the local mailbox.

If you only have a few people that need the service, this method may be enough to meet your needs.  On my server, I only have a small handful of people with Blackberries, so I haven't been able to justify the cost (Money and time) of setting up and managing BES quite yet."
 
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Another Blackberry Server on SBS install guide

_______________________________________________________________

Article on Windows Time

Nice article.
 
 

Windows Time and the W32TM service

Windows Time and the W32TM service

Nathan Winters

Introduction
In the last few days this issue of time sync in Windows domains has come up a few times both at work and on the Minasi forum of which I am a member. Each time there has been confusion as to exactly how time sync occurs in a Windows domain.Therefore, I decided that I would put this article together in order to try to provide a decent answer as to what is going on and how to troubleshoot any issues that arise.

The first thing about Time Sync in Windows is to realise that it is a little different between Windows 2000 machines and Windows XP/2003 machines. This is because in Windows 2000 the Simple Network Time Protocol (SNTP) was used and was configured with the NET TIME command. Now, with XP and 2003, Network Time Protocol (NTP) is used which give benefits such as more reliable time due to better correction methods. This is configured using the new W32TM commands which we will look at later on.

To start with, however, I will look at the principles that remain the same for both Windows 2000, 2003 and XP computers/domains.
Time Sync Principles
Why time sync:
The first question that we need to ask ourselves is why do we need time synchronisation? Well, in an Active Directory domain, it is very important for all clocks to be within 5 minutes of each other (by default) due to the implementation of the Kerberos protocol for authentication which relies on time stamped packets to prevent amongst other things, man-in-the-middle attacks. Another reason time sync is important for is because now Active Directory uses multi-master domain controllers (DCs) it is important that changes made at a later actual time on one DC don’t get overwritten by similar changes on another DC whose time is set wrong thus making it look like the most recent change!

What is Network Time Protocol
Network Time Protocol (NTP) is the default time synchronization protocol used by the Windows Time Service (WTS) in Windows Server 2003 and Windows XP. It should be noted that this is different from Window 2000. As I will mention in the Windows 2000 specific section later on, Windows 2000 used the Simple Network Time Protocol (SNTP) to do time sync. However, for now we will talk about NTP as is contains all the functionality of SNTP and more!

NTP time synchronization takes place over a period of time and involves the transfer of NTP packets over a network. NTP packets contain time stamps that include a time sample from both the client and the server participating in time synchronization.
NTP relies on a reference clock to define the most accurate time to be used and synchronizes all clocks on a network to that reference clock. NTP uses Coordinated Universal Time (UTC) as the universal standard for current time. UTC is independent of time zones and enables NTP to be used anywhere in the world regardless of time zone settings.

What are we configuring within Windows
The Windows Time Service (WTS), that’s what! As you can tell from the name, this is a service that runs on Windows machines and understands and implements network time sync using NTP. To enable the WTS to be flexible, it works by using plug in time providers. This allows it to support both hardware and Internet based time sources.

The NTP provider is the standard time provider included with Windows Server 2003. The NTP provider follows the standards specified by NTP version 3 for a client and server, and can interact with SNTP clients and servers for backward compatibility with Windows 2000 and other SNTP clients.

The NTP provider in the Windows Time service consists of the following two parts:

NtpServer output provider. This is a time server that responds to client time requests on the network.

NtpClient input provider. This is a time client that obtains time information from another source, either a hardware device or an NTP server, and can return time samples that are useful for synchronizing the local clock.

The Windows Time service is implemented in a dynamic link library called W32Time.dll. W32Time.dll is installed by default in the Systemroot\System32 folder during Windows Server 2003 setup and installation.

Time Protocol Interoperability
As is often the case with developments in the Windows environment, the new technology can still talk to the old. In this case, this means that the Windows Time service can operate in a mixed environment of computers running Windows 2000, Windows XP, and Windows Server 2003, because the SNTP protocol used in Windows 2000 is interoperable with the NTP protocol in Windows XP and Windows Server 2003.

Time Sync Hierarchy and Stratum:
The degree to which a computer’s time is accurate is called a stratum. The most accurate time source on a network (such as a hardware clock) occupies the lowest stratum level, or stratum one. This accurate time source is called a reference clock. An NTP server that gets its time directly from a reference clock becomes part of a stratum that is one level higher than that of the reference clock. Resources that get time from the NTP server are two steps away from the reference clock, and therefore are part of a stratum that is two higher than the most accurate time source, and so on. As a computer’s stratum number increases, the time on its system clock may become less accurate. Therefore, the stratum level of any computer is an indicator of how closely that computer is synchronized with the most accurate time source.

Windows 2000/3/XP ensures time is synchronised correctly within a domain by setting up a time sync hierarchy which follows the model above. The Primary Domain Controller emulator (PDCe) of the forest root is the Master Time Server (effectively stratum 1 for the network, although you could see this as stratum 2 as the PDCe also syncs with a more accurate clock). Other DCs then sync with the PDCe and clients and member servers sync with their authenticating DC. Therefore you have one point of “Reliable Time” in the enterprise, the root PDCe. So you might now be asking; what should I sync the root PDCe to?

Well, there are several choices; you don’t have to sync the box at all! So long as all the machines within your network share the same time, it doesn’t matter what time it is (unless you use time for other purposes). However, since you are likely to want the correct time on all your machines the other options are, either to sync the root PDCe with a hardware clock or to sync it with a public time server on the Internet.
Once you have setup the PDCe to sync with an external time source then what happens? Well, it tries to sync every 45 minutes until it achieves its first sync. Then after that, it syncs again every 45 minutes until it has done three successful syncs in a row. After that it syncs once every 8 hours.
You should also note that if the time is more than 3 minutes out then the w32time service will use a process of gradual adjustment to bring things into line rather than simply changing the clock immediately.
Reliable Time Source Configuration
If a domain controller is configured to be a reliable time source, in other words, it syncs with an external time source, the NetLogon service announces that domain controller as a reliable time source when it logs on to the network. When other domain controllers look for a time source to synchronize with, they choose a reliable source first if one is available. When a DC is intended to be a reliable time source you should ensure that the following registry key has a value of 5 if not then the default value 10 should be left in place.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time

\Config\AnnounceFlags

Windows 2000 Time Sync
I am now going to look at how you setup your Windows 2000 machine to sync over the Internet and what protocol Windows 2000 uses to do this. As mentioned briefly above, this is one of the differences between Windows 2003/XP and 2000. The protocol used for Windows 2000, is called Simple Network Time Protocol or SNTP. It is a “simple” version of NTP and lacks some of the more complex algorithms which provide more accurate and stable time for NTP clients. The way you set this up is to use the command line to enter the following:
NET TIME /SETSNTP:dnsnameofserver
For example, you could use the following:
NET TIME /SETSNTP:time.window.com
If you what to find out which server you setup a machine to sync to you can use the following command:
NET TIME /QUERYSNTP

Windows 2003 uses W32TM not NET TIME
As I mentioned above, Windows Server 2003 and Windows XP now use NTP instead of SNTP. Alongside that they now have a new way of configuring the WTS. The command that now does everything regarding WTS is:

w32tm

So how do we use it? Well, the first thing to look at is the “/config” parameter. This does a few things. It allows you to use “/computer” to specify which computer you are setting up. The default setting is the local machine but it is nice that you can administrate time on remote computers too! It also allows you to tell the WTS that its config has changed and that it should apply the changes by using the “/update” switch. However, the two most important parameters are:

/syncfromflags:MANUALorDOMHIER
/manualpeerlist:PEERS
These parameters tell the computer whether or not to look for a time server within an Active Directory hierarchy or whether it should sync from and external source and then, if so, what that source is! What these parameters actually do is control a registry entry called "Type" in:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
This key is either set to "NT5DS" if you're in an AD, or "NTP" if you're either not an AD member, or if you're the root domain's PDCe. Actually, this key could also be set to “NoSync” to prevent any time sync taking place.
To tell a system's W32Time service to get its time from the Active Directory, type
w32tm /config /syncfromflags:domhier /update
This does two things. First, it sets that Type value to "NT5DS." Second, it notifies the w32time service that settings have changed.
If the system is not a member of and AD or is the root PDCe then change two things. First, the value of the “/syncfromflags” option changes from "domhier" to "manual" which changes the “Type” value from "NT5DS" to "NTP". Second, add the “/manualpeerlist:” option, to tell it where to sync from. Adding the “/manualpeerlist:” actually adds the entry specified to another key under the location above. The key is called “NTPServer”.
For example, to tell your system that it should do its own time sync from time.windows.com, type:
w32tm /configure /manualpeerlist:time.windows.com,0x1 /syncfromflags:manual /update
Note: if using a DNS name for the time server then it is important to add the 0x1 to the end. If using and IP address this can be omitted.
After making any changes to the w32time service configuration you should restart the W32TIME service. This can be done from a command prompt as follows:
net stop w32time && net start w23time
After issuing either of these commands, you should tell your system to update its time with the following command:
w32tm /resync /rediscover
So that gets you the basics setup for a Windows Server 2003 or Windows XP machines.
To see a list of all the commands you can use with w32tm, type:
W32tm /?
Locating Time Servers:
By the way, if you are wondering where to find time servers to sync with I would recommend that you look into the NTP pool project which in its own works does the following:
“The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers.”
For more info see http://www.pool.ntp.org
One tip that may be useful to someone during the search for a timeserver is this; if you think that a machine is running a time server then try the utility ntpquery.exe found at the following link:
http://www.bytefusion.com/products/fs/ntpquery/ntpquery.html
Point it at either a DNS name or IP address and if it returns box like the one in the screenshot below, then you have found a time server!

Another way to verify whether a machine is a time server is to use the w32tm /monitor command. This can be used as follows:
W23tm /monitor /computers:uk.pool.ntp.org
w32tm /monitor /computers:uk.pool.ntp.org
uk.pool.ntp.org [82.71.9.63]:
ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
NTP: -4.9009063s offset from local clock
RefID: utserv.mcc.ac.uk [130.88.200.6]

You should get output similar to the above. In particular the NTP: line which shows that my clock is 4 seconds behind the online time server.

Best Practice:
Preventing Large Time Changes
As I have already stated, it is highly recommended to setup your root PDCe to sync with an external time source of some sort. However, having done this, you are then open to a possible problem caused by an error with the clock you sync to. If something were to go wrong and the time were to change dramatically on your external clock your root PDCe would by default follow this time change and apply it. This would then filter all through you domain which obviously would be a bad thing!

To prevent this you should configure the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. From Microsoft sources on the Internet, it would appear that the recommended value is 900 seconds (15 mins). I would suggest that having a 15 minute time change occur on your network is likely unacceptable. I would therefore recommend setting this interval for 300 seconds so that the time change internally is never greater than 5 minutes. This should help to prevent problems if a large change was received which then prevented Kerberos authentication working as some machines would have a time difference of greater than 5 minutes before full time sync could occur.

If you are particularly worried about this type of problem then you could also set the values for your internal systems as well as for your root PDCe. For a little more info about these keys, including where to find them, look in the table below:

Obviously the above also means that if your clock were to get a long way out then correction wouldn’t be automatic. In this case you should monitor the time of your network fairly regularly and also set the value of the MaxPollInterval registry entry to 10 or less, or that you set value of the SpecialPollInterval registry entry to 3600 (1 hour) or less to enable frequent time checks.

As with all these setting changes for more information have a browse of the Windows Time Service Technical Reference which can be found through the link below:

http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true

Troubleshooting Time Sync
The first thing to note about troubleshooting is that in Windows 2000, there is not much logged to the event log. However, this is changed with 2003 so your first step would be to check out the messages logged there.

In order to really see what is going on, you should then look to make use of w32tm and investigate the relevant registry keys mentioned above. Finally you can also enable debug logging for the w32time service. Whilst this can be useful, it does output a large amount of information of which lots may be unintelligible. It is for this reason that it is often useful only when working with MS PSS to solve your problem.

My Troubleshooting steps:
Here are the steps I take when troubleshooting Time Sync issues on a PDCe box.

1. First I will investigate the forest structure looking at how many domains and DCs exist. Then on one of the DCs I will install the Windows 2003 support tools and type

netdom query fsmo

2. This will locate the holders of the FSMO roles and allow me to find the server holder the PDCe role.

3. I will then verify with replmon that good replication is occurring within the forest.

4. I will next use the NTPQuery utility mentioned above to verify that the time.windows.com time server can be accessed from the machine. This will verify that the relevant ports are open. Another way of doing this would be to use portqry as shown below which should return a Listening or Filtered output

portqry –n time.windows.com –e 123 –p UDP

5. Next I will open up regedit and locate the registry key below. Once there I will check that the desired time server is configured and that if a DNS name is used the ,0x1 suffix is used:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

6. I will next attempt to ping the server that is referred to. Although this is not always possible due to settings at either end, it does provide a clear indication that the server is available. Another way to get this verification would be to use the portqry command above.

7. Open Registry Editor (regedit.exe) and configure the following registry entries so that it is set to NTP not NT5DS:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type

8. Whilst in the registry ensure that the registry key below has a value of 5.

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags

9. Now stop and restart the Windows Time service using the following command:

net stop w32time && net start w32time

10. Next re-sync the w32time service using the following command:

w32tm /resync /rediscover

11. Next check in the system event log to see if errors are still logged. If the above has fixed the problem then you should now receive an event ID of 35 logged by the w32time service.

12. If you still have errors then reboot the server.

13. Then in the registry point the time server to the same time source as above but use the 0x8 flag instead of the 0x1 flag to force W32time to send normal client requests.

14. Restart the w32time service as shown above and check the event log. If errors continue carry on as follows.

15. Check the Default Domain Controllers group policy and the Default Domain group policy and any others that could affect the PDCe or other DCs. Check the following areas:

Computer configuration/Administrative Templates /System/Windows Time service/Time Providers

Ensure that all three settings listed are set to “not configured”.

16. Now stop and restart the Windows Time service using the following commands:

net stop w32time && net start w32time

17. At this point check the system event logs and you should see event id 35
18. If you are still having problems then as a final attempt, you can un-register and re-register the w32time service. This will clear out all configurations and let you start again from scratch. The details of how to do this are in the next section titled “Other useful w32tm commands”.
Other useful w32tm commands:
A couple of other w32tm commands that may well be useful in your troubleshooting are as follows:

W32tm /unregister
W32tm /register
W23tm /dumpreg

The first command will remove all w32time service registry keys and settings and un-register the w32time service. This effectively wipes all configuration from the machine.

The second command will register the service and set it up with default settings ready for your configuration.

The third command is useful for both documentation and reporting to PSS as it enables you to export the contents of the w32time registry key. To be honest though, I find it easier to use regedit to do this.

A final tip is that after any changes you should restart the w32time service
How to turn on debug logging:
In order to turn on debug logging you must create a location for the log. I would use “c:\w32tmlog”. Next open up regedit and make the following changes:

Locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
On the Edit menu, click New Value, and then add the following registry values:
• Value Name: FileLogSize
Data Type: DWORD
Value data: 10000000

This registry value specifies the size of the log file in bytes.

• Value name: FileLogName
Data Type: String
Value data: C:\w32tmlog\w32time.log

This registry value specifies the location of the log file. The path is not fixed. You can use a different path.

• Value name: FileLogEntries
Data Type: String
Value: 0-116

This registry value specifies the level of detail of the information in the debug log. If you must have more detailed logging information, contact a Microsoft Support Professional.

Note The Data Type value must be of type REG_SZ (String). You must type the value exactly as shown (that is, type 0-116). The highest possible value is 0-300 for most detailed logging. The meaning of this value is: Log all entries within the range of 0 and 116.

The information above has been taken from the following MS KB article:

http://support.microsoft.com/kb/816043/

References
Below are some links to pages I found useful when researching this article.

The
http://technet2.microsoft.com/WindowsServer/en/library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx?mfr=true

How to configure the Windows Time Service against a large time offset:
http://support.microsoft.com/kb/884776/

Registry entries for the W32Time Service:
http://support.microsoft.com/kb/q223184/

How to configure Debug logging:
http://support.microsoft.com/kb/816043/

How to configure and authoritative time server in Windows Server 2003:
http://support.microsoft.com/kb/816042

http://labmice.techtarget.com/windows2000/timesynch.htm

http://www.pool.ntp.org/


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Step-by-step on RPC over HTTP

 
Good blog this one.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Nice step by step on creating a L2TP connection to a Juniper Netscreen 5GT

I used to use Netscreens a bit and found them somewhat less than simple documentation wise. Here's a really nice step through
 
 
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

True Crypt - Opensource BitLocker alternative

 
It's the encryption of the boot partition that looks so interesting
 

Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux

Main Features:
 

 

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

How to uninstall a failed WSUS 3.0 installation

There's a reg key as well that helps, but here's some good dirt
 
 
 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Saturday, May 3, 2008

Poor Man's ShadowProtect?

I had a quick play with the VMWare Personal Backup Appliance on the weekend. The RC did not work for me, but the stable version went very well for backing up and restoring a VM server. It’s applications? Bit of extra safety perhaps?

 

http://www.vmware.com/appliances/directory/321

Thursday, May 1, 2008

XP SP3 blocker tool needed

From Patch Management Mailing List

To: Patch Management Mailing List
Cc: WSUS Mailing List
Subject: XP SP3 blocker tool needed

HI all,

We are not ready for SP3 to hit our desktops anywhere. It would need to
be thoroughly tested (the full release not the RC's) on a wide range of
hardware and software configurations before it could be allowed to hit
our desktops. We have a couple thousand stations that are not pointed
to WSUS at all but rather to windows automatic update. Unless a blocker
is deployed to those stations they will get SP3.


So my question was, has M$ released or will M$ release a blocker for SP3
in the same vein as the IE7 blocker. The answer is YES. At this link
http://www.microsoft.com/downloads/details.aspx?familyid=d7c9a07a-5267-4
bd6-87d0-e2a72099edb7&displaylang=en&tm you will find a service pack
blocking toolkit. The only caveat with this is it appears to block any
service pack but only for 12 months following official release. I
think that means the stations will still download and install XP sp2 if
they need it. If you run it on Vista SP1 will be blocked for 12 months
from its's release date.

I thought this might be useful for others. I'm going to make our
community aware of this tool over the coming days and encourage it's use
on any stations not using WSUS until we have validated and approved SP3
in our environment.

Regards,
Blaine


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

______________________________________________________________________