IT Resource

There’s been some wild and panicky stuff in some of the Tech press lately about a potential exploit that could bypass Vista’s security model. It all sounds pretty drastic but please bear in mind that most reports have been pretty sensationalist about it.

A ZDNet blog post contains a bit more ‘measured’ information about it along with responses from one of the guys who reported the exploit.

Microsoft is inviting customers and partners to begin evaluating pre-release versions of Windows Small Business Server 2008 and Windows Essential Business Server 2008.

Due for general release later this year, Microsoft has overhauled its licensing terms following customer feedback on its current Windows Small Business Server 2003 R2 offering.

The new licensing terms mean that customers will be able to purchase single client access licences, allowing them to pay only for the exact number of employees using the product.
Read more…

It is the type of vulnerability that Microsoft wanted to head off as long as possible, especially since Windows Vista’s new kernel was designed to thwart this possibility.

Now, as the company acknowledged in a security bulletin yesterday, a malicious program running as a local or network service can leverage another local or network service running in the same system, to elevate its own privilege and potentially cause damage.

As of early Friday evening, there was no known exploit for this vulnerability, and thus security firm Secunia has given it a “less critical” rating. The nature of Microsoft’s report today indicates that it may have been alerted to the problem by a security engineer who discovered a proof of concept, though no credit has yet been given.
Read more…

The downtime experienced by Windows Server 2003 increased 25 percent to nine hours per server per year, while the reliability of mainstream server-based Linux distributions improved significantly, according to a Yankee Group survey.

The 2007-2008 Global Server Operating System Reliability Survey presents a substantially different picture compared to the results of the last such survey in 2006, in which Windows administrators reported less downtime than their counterparts who used Linux — a result that stirred up controversy at the time.

Over 2007 and 2008, Linux distributions from Red Hat and Novell increased reliability by an average of 75 percent, respondents to the survey said.

Downtime on Windows Server 2003, increased by 25 percent, to nearly nine hours per server, per year.
Read more…

There is a really neat way that you can quite easily find all active/used IP Addresses on your network without the need for any third party applications or worse, pinging each IP Address individually.

Open the Command Prompt and type in the following:

Change 192.168.10 to match you own network.

By using -n 1 you are asking for only 1 packet to be sent to each computer instead of the usual 4 packets.

The above command will ping all IP Addresses on the 192.168.10.0 network and create a text document in the C:\ drive called ipaddresses.txt.  This text document should only contain IP Addresses that replied to the ping request.

Although it will take quite a bit longer to complete, you can also resolve the IP Addresses to HOST names by simply adding -a to the ping command.

GUI Based Discovery

If you’re not confident using the command prompt, there are alternative GUI based applications that you can use.

TCPNetView – No installation is required, simply double-click the executable and away it goes.  It will find all active IP Addresses on the subnet you are currently connected too.
- Download Here

Advanced IP Scanner – If you are after something with a few more options and features, Advanced IP Scanner is an excellent free utility.
- More Information Here

Have you ever wanted to remove Windows components like Media Player, Internet Explorer, Outlook Express, MSN Explorer, Messenger and more from your Windows installation?  Have you ever wanted to include Service Packs and/or other Windows updates in your installation?  How about the integration of device drivers or even the creation of an unattended installation?  If the answer is ‘yes’ to any or all these questions, then nLite is the tool for you, and I can’t recommend it more highly!

nLite is a tool for pre-installation Windows configuration and component removal at your choice. Optional bootable image ready for burning on media or testing in virtual machines.

With nLite you will be able to have Windows installation which on install does not include, or even contain on media, the unwanted components.

Features

• Service Pack Integration
• Component Removal
• Unattended Setup
• Driver Integration *
• Hotfixes Integration **
• Tweaks
• Services Configuration
• Patches ***
• Bootable ISO creation

* – Textmode (CD Boot) and normal PnP
** – hotfixes with white icons, *KB*.exe, including update packs
and Internet Explorer 7
*** – supports generic SFC, Uxtheme, TcpIp and Usb Polling patching.

nLite supports Windows 2000, XP x86/x64 and 2003 x86/x64 in all languages.

If you would like to know more about nLite, or to download the software, visit the nLite website at http://www.nliteos.com

No, you don’t have to pay a cent for nLite.  Infact, nLite is completely free!  That said, I’m sure they would appreciate a donation.

Data Execution Prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system. In Microsoft Windows XP Service Pack 2 and Microsoft Windows XP Tablet PC Edition 2005, DEP is enforced by hardware and by software.

The primary benefit of DEP is to help prevent code execution from data pages. Typically, code is not executed from the default heap and the stack. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. Software-enforced DEP can help prevent malicious code from taking advantage of exception-handling mechanisms in Windows.

There may come a time when have to disbale DEP either for the purpose of troubleshooting a problem or otherwise.  Below I have provided instructions on doing just that.

Disable Data Execution Prevention (DEP)

1. Right click on My Computer and Select Properties.
2. Click the Advanced tab, and in the Startup and Recovery section, click the Settings button.
3. In the System Startup section, click the Edit button.
4. Now find the text that says /noexecute=OptIn.
5. You need to replace OptIn (which the default) with AlwaysOff.


Be sure to enter this text carefully and exactly as it’s mentioned above. Failure to do so could prevent your computer from booting.

Your boot.ini file should read:/noexecute=AlwaysOff

6. Click File and then click Save.
7. Click OK to close Startup and Recovery window.
8. Click OK to close System Properties windows
9. Restart your computer.

This setting does not provide any DEP coverage for any part of the system, regardless of hardware DEP support.

Verifying DEP is Disabled

1. Right click on My Computer and select Properties.
2. Click the Advanced tab.
3. In the Performance section, click the Settings button and then click Data Execution Prevention tab.
4. None of the DEP settings should be available.  Click OK to close Performance Settings window.
5. Click OK to close System Properties window.

DEP is now completely disabled. If you want to enable it again, follow this guide but instead of replacing OptIn with AlwaysOff, replace AlwaysOff with OptIn (the default).

Each version of Exchange Server includes a build number so that you can easily identify which version of the software you are running.

Open the Exchange System Manager, expand Servers, right-click your server, click Properties, select the General tab (if it isn’t already selected) and you should see something similar to this:

Exchange 2000

4417.5 – Exchange 2000 RTM
4629.1 – SBS 2000 Exchange 2000
4712.7 – Exchange 2000 SP1
5762.4 – Exchange 2000 SP2
6249.4 – Exchange 2000 SP3

Exchange 2003

6944.4 – Exchange 2003 RTM (including SBS2003)
7226.6 – Exchange 2003 SP1
7638.2 – Exchange 2003 SP2

This guide will run you through the steps required to transfer the Flexible Single Master Operations (FSMO) roles (also known as operations master roles) by using the Active Directory snap-in tools in Microsoft Management Console (MMC) in Windows Server 2003.

FSMO Roles

In a forest, there are at least five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:

• Schema Master: The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.
• Domain naming master: The domain naming master domain controller controls the addition or removal of domains in the forest. There can be only one domain naming master in the whole forest.
• Infrastructure Master: The infrastructure is responsible for updating references from objects in its domain to objects in other domains. At any one
  time, there can be only one domain controller acting as the infrastructure master in each domain.
• Relative ID (RID) Master: The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. At any one time, there can be only one domain controller acting as the RID master in the domain.
• PDC Emulator: The PDC emulator is a domain controller that advertises itself as the primary domain controller (PDC) to workstations, member servers, and domain controllers that are running earlier versions of Windows. For example, if the domain contains computers that are not running Microsoft Windows XP Professional or Microsoft Windows 2000 client software, or if it contains Microsoft Windows NT backup domain controllers, the PDC emulator master acts as a Windows NT PDC. It is also the Domain Master Browser, and it handles password discrepancies. At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can use one of the following three MMC snap-in tools:

• Active Directory Schema snap-in
• Active Directory Domains and Trusts snap-in
• Active Directory Users and Computers snap-in

If a computer no longer exists, the role must be seized. To seize a role, use the Ntdsutil.exe utility.

Transfer the Schema Master Role

Use the Active Directory Schema Master snap-in to transfer the schema master role. Before you can use this snap-in, you must register the Schmmgmt.dll file.

Register schmmgmt.dll

1. Click Start, and then click Run.
2. Type regsvr32 schmmgmt.dll in the Open box, and then click OK.
3. Click OK when you receive the message that the operation succeeded.

Transfer the Schema Master Role

1. Click Start, click Run, type mmc in the Open box, and then click OK.
2. On the File, menu click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Schema, click Add, click Close, and then click OK.
5. In the console tree, right-click Active Directory Schema, and then click Change Domain Controller.
6. Click Specify Name, type the name of the domain controller that will be the new role holder, and then click OK.
7. In the console tree, right-click Active Directory Schema, and then click Operations Master.
8. Click Change.
9. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the Domain Naming Master Role

1. Click Start, point to Administrative Tools, and then click Active Directory Domains and Trusts.
2. Right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller.

Note: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer.

3. Do one of the following:

In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK.

- or -

In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations Master.
5. Click Change.
6. Click OK to confirm that you want to transfer the role, and then click Close.

Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles

1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Right-click Active Directory Users and Computers, and then click Connect to Domain Controller.

Note: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer.

3. Do one of the following:

In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK.

- or -

In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.

4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Master.
5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and then click Change.
6. Click OK to confirm that you want to transfer the role, and then click Close.

And there you have it. How to view and transfer FSMO roles in Windows Server 2003.

You can use the Remote Desktop feature in Microsoft Windows XP and Windows 2003 to connect to a remote computer.  The default port Remote Desktop listens on is 3389.

Note: The Remote Assistance feature in Microsoft Windows XP may not work correctly if you change the listening port.

To change the port that Remote Desktop listens on, follow these steps:

1. Start the Registry Editor by click on the Start button, selecting Run, type in regedit, and then press Enter.
2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TerminalServer\WinStations\RDP-Tcp\PortNumber

3. On the Edit menu, click Modify, and then click Decimal.

4. Type the new port number, and then click OK.

5. Quit Registry Editor.

To connect to the computer you changed the listening port on, you must specify the port number in the Remote Desktop Connection dialogue box. For example, instead of just typing the computer name, you need to add Portnumber to the end (where portnumber is the listening port).

Default – No port specified – connecting to the default port of 3389.

Adding the listening port number to the computer name.

Along with the new Windows Firewall in Windows Server 2003 SP1 and Windows XP SP2, Microsoft provided an updated system.adm administrative template file that adds Group Policy settings that you can use to configure firewall behavior at a local machine policy level or by using an Active Directory-based Group Policy Object (GPO). To access the Windows Firewall Group Policy settings, open either a local machine policy (run gpedit.msc on a workstation) or a GPO stored in a domain. Expand Computer Configuration, Administrative Templates, Network, Network Connections, and Windows Firewall.

You can configure firewall settings under both the Domain Profile and Standard Profile subfolders. You use the domain profile when the computer is connected to the Active Directory network and the standard profile when the machine isn’t connected to the corporate network. This setup lets you configure different settings for networked machines and remote machines, as this figure shows.

Click to enlarge

The options under each of the two branches are identical, and you can click an item to view its description. Here are some key settings you may want to enable:

1. Windows Firewall: Protect all network connections. This setting essentially forces the firewall on or off for the profile.
2. Windows Firewall: Do not allow exceptions. This option instructs the firewall to ignore any exceptions that have been defined. Enabling this setting is equivalent to selecting the “Don’t allow exceptions” check box on the General tab of Windows Firewall in Control Panel.
3. Windows Firewall: Define program exceptions Properties. This setting lets you define custom programs, to which you can then grant exceptions to pass through the firewall.
4. Windows Firewall: Prohibit notifications. This setting stops the firewall from prompting users whether they want to allow exceptions for a currently stopped program.
5. Windows Firewall: Allow logging. This option lets you configure the logging level for the firewall, the log size, and its name and location.

For more information about Windows Firewall policy settings, see Windows Firewall Technical Reference in the Network Security Technologies section of the Networking Collection on the Microsoft Windows Server 2003 TechCenter site on TechNet.

Although this is a rather old subject, I was recently approached by someone experiencing difficulties with Exchange 2003 SP2 and IMF (Intelligent Message Filter) so I thought I would quickly let you all in on a little tip, for those of you who haven’t as yet installed Exchange 2003 SP2, which I can’t imagine would be too many of you.

Before you start installing SP2, you need to uninstall the Intelligent Message Filter (IMF). By doing this, the settings from the SMTP virtual server where you allowed filtering are also removed.

After the SP2 installation, go to Intelligent Message Filtering settings (Global Settings -> Message Delivery -> Properties -> Intelligent Message Filtering tab) and setup IMF with the same settings as earlier. However, that alone does not reactivate IMF.

You still need to enable IMF from the SMTP virtual server properties -> General tab -> Advanced Edit and check “Apply Intelligent Message Filter” – just as you need to check the relevant options for recipient filter, connection filter, sender filter, and the new option of applying SenderID filter.

Hopefully someone finds this information in some way useful.

The following commands can be run from any NT 4.0, W2K, XP Pro, or Windows 2003 Server computer.

Note: You must add the /domain switch to the commands otherwise it will be performed on the local SAM and not the Domain Controller SAM.

For example, if you wanted to change the password of a local user account, type the following:

net user account password_here

Replace account with the user’s username.

To change a user’s domain password at the command prompt, log on as an administrator and type:

net user account * /domain

You will be prompted to type a new password for the user and then asked to type it again to confirm it.

The password should now be changed.

Alternatively, you can type the following command:

net user account password /domain

By using this command, the password changes without prompting you to confirm it. Because you aren’t prompted to confirm the password, it allows you to change multiple passwords of different user accounts from within a batch file.

If you attempt to change a password from an account without administrator privileges, you will receive an error message like “System error 5 has occurred. Access is denied.”

Whereas Exchange 2003 really offers only one type of clustering support (local, with multiple servers sharing a SAN), Exchange 2007 supports log shipping both remotely and locally, which opens up new modes of clustering:

• Local Continuous Replication (LCR ), a single-server solution in which the system uses the logs to create a second copy of a storage group (SG) on a different set of disks. This method gives you a second copy of the data. More information here.
• Cluster Continuous Replication (CCR), a two-server solution in which the system ships the logs to a second server to maintain a second copy of the SG. This second server can be local or remote. More information here.
• Single Copy Clusters (SCC), the same idea as Exchange 2003 clusters, in which one set of data is connected to multiple servers. More information here.

Exchange Server 2003 had a basic set of server roles: a back-end server that hosts information stores and performs the bulk of processing and front-end servers that accept client requests and proxies them to the appropriate back-end server. Exchange 2007 has a more granular set of server roles to give flexibility to larger Exchange deployments, while still allowing small to medium deployments to host all the required roles on one server if appropriate. The server roles are:

• Mailbox – Hosts mailbox and public folder data. This role provides Messaging API (MAPI) access for Microsoft Outlook clients. Additionally a variation exists called the Clustered Mailbox role when hosting as part of a clustered environment; it requires no other Exchange roles running on the cluster instance

• Client Access – Similar to the old front-end server role. Provides all other client protocol access, apart from MAPI (i.e., Outlook Web Access–OWA, POP3, IMAP, and ActiveSync)

• Unified Messaging – Provides client access to mailbox, address box, and calendar via telephone and voice. Require Special IP-PBX or VoIP gateway software.

• Hub Transport – Mail routing server that forwards mail to another hub transport server, edge server, or mailbox server. Unlike Exchange 2003, which uses Exchange routing groups, Exchange 2007 uses Active Directory (AD) sites.

• Edge Transport – Gateway from the Exchange organization to the outside world. This is the last hop for outbound mail and the first hop for incoming mail. This is the server that provides mail quarantine. This role doesn’t require AD access, making it ideal for perimeter deployment without opening up ports for AD access. This role must always be deployed on a server with no other Exchange roles.

The Mailbox, Client Access, Unified Messaging, and Hub Transport roles can be distributed across multiple servers or in combination with each other on potentially one server. Any AD site with a Mailbox role also requires a server in the same AD site running the Hub Transport and Client Access roles (or they can be installed on the Mailbox role server).