DNS Issues with Server 2008 R2

RFC 2671.  This shouldn’t mean much of anything to most of us. This RFC Code, however, can literally mean hours and hours of frustration and troubleshooting if you have created a Server 2008 R2 domain.

Developed in 1999, Extension mechanisms for DNS aka eDNS, were designed to allow for increased functionality of the DNS protocol. They were also critical to the implementation of DNS Security Extensions (DNSSEC). Nevertheless, the protocol hasn’t really caught on and there are still thousands of devices – even ones produced today – that are not really fully compliant with the standards laid out in RFC 2671.

Naturally, the Internet itself is a inter-connected network that is literally running on loads of old and obsolete equipment.  So, it comes as no surprise that there are going to be a few problems arising from the fact that Windows Server 2008 R2, when set up as a DC with the DNS role installed and set to perform recursive lookups, has this extension to DNS enabled by default.

Not everyone, fortunately, will have issues with this as there are of course DNS servers out there that will respond properly to this type of query and respond with the IP address requested. However, if you happen to be running DNS queries against one that is non-compliant, you will end up with extremely patchy Internet service for your whole domain.

To check if this is an issue for your domain, you are going to have to run a few tests.

Open network monitor, and look at the DNS queries that you are getting. If they look like the picture below, you are probably encountering this issue.

The fix, luckily, is very simple.  Simply disable eDNS and re-enable it at some point in the future when acceptance of this protocol is a little higher.

Open up a cmd prompt and elevate it (right click on it and run it as an administrator). Then run the following command.

dnscmd /config /EnableEDNSProbes 0

This should take effect immediately.

I sincerely hope that this helps a few of you out there that are just starting to deploy Server 2008 R2 now that SP1 is out.

Cheers!

Matt

Repairing an Exchange 2007 Database

As system administrators, there is nothing quite like the feeling you get when you are staring at a downed exchange server. Honestly, there is very little that would impact end users more than the loss of email. Unwittingly, I have even had a whole DC go down for several hours unnoticed just due to the fact that email and Internet was still working.  Losing exchange is a big deal.

All versions of exchange, despite their overwhelming complexity, have several tools available to help one repair and/or recover an exchange data store. Today’s post will mainly focus on Exchange Server 2007, but again, a lot of these tools are available with 2003 and will be available in the 2010 version.

Before we begin this, I think we are all working under the assumption that there is a recent and intact backup available. If there isn’t, I really must say – all bets are off. Backup! Backup! Backup…not doing so is playing with your career!

More often than not, the first tool you will use when dealing with Exchange database issues is the Database Recovery Management Tool. This tool can be found under the toolbox section of the exchange management console and will offer a lot of insight into why the database has failed. In worst case scenarios, it may even be able to recover the database to a working state.

Some of the functions of this tool are:

• to verify databse and transaction log files 
• to analyze log drive space
• to reset the log generation number
• to repair a database
• to show database-related event logs
• to merge or copy mailbox content
• to set the database can be overwritten by restore option.

One word of caution here though – the repair database option can and often does result in permanent data loss. Only use this option if you do not have a backed up database to restore from and this is your only option.

Another handy tool that can be used to work with your exchange databases is the Database Troubleshooter tool.

This is handy when you are faced with a database that will not mount, or there is some inconsistency in the log files due to them being excessively long or from a drive space issue.  The tool is pretty straightforward and will systematically test the database to identify issues stopping a successful connection and/or mounting.

The third tool that can be used is the venerable Exchange Server Database Utility often known as the ese utility.  The tool is located in the default Exchange install folder in the bin directory and can be used in many ways from the command line to repair or recover and exchange database. Again, another word of caution is needed here. The ese utility can result in data loss, so your first and best bet is to always try restoring from backup first if at all possible. In fact, the repair function in the (the /P switch) ese utility works by going through pages in the database that seem unrecoverable and simply discarding them to bring the database back into a consistent state. If that sounds a little scary too you, I am glad that you are fully comprehending the gravity of that switch. The /R switch will attempt to recover the database by rolling back or updating database files by replaying the transaction log. This, while time consuming, often works well in fixing the information store up.

One thing that should be mentioned at this time also – to use the eseutility, you have to dismount the database first.

Use the following command from the exchange management console to do this.

Dismount –Database –Identity “DBName\First Storage Group\Mailbox Database”  After running any of these commands, it is also advisable to use the /D switch to defragment the database as repair operations will often leave large areas of white space.

Finally, Exchage 2007 has a tool known as the integrity checker (isinteg.exe). This tool is effective in fixing relationships between databse tables such as the “public Folders” and mailbox tables. It runs at the logical schema level and because of this attempts to repair inconsistencies at the application level.   This tool is designed for disaster recovery and is often run after you have recovered a mailbox store using the eseutility or from backup.

Unfortunately, Exchange repair is never a fast or particularly fun task, but knowing and practice using the tools above will help alleviate the pressure of production server failures. Set up your own exchange environment, populate it with some garbage, and then practice breaking and recovering the database as many times as you can stomach. Try using a hex editor to cause corruption in the database and see how these tools work.  Trash it and see what you can do!

Good Luck.

LLMNR – Another Reason to Upgrade

The ultimate goal of any network administrator is system uptime and the consistent availability of network resources . This should be easy, but alas DNS and WINS can be fickle creatures.

In the Windows 2000/Windows XP days, losing a DNS server usually meant a total lack of connectivity for a network.  WINS, while not nearly as important as it once was, was also the source of a lot of grief when it wasn’t working properly.

Now, we have IPv6 entering the scene which has created its own set of problems. WINS doesn’t support it at all, and DNS is not so keen on mixing the two types of addresses (although it is possible). The need for a technology to fill the gap was evident. There had to be a better way of keeping machines talking to each other on subnets.

The answer was LLMNR or Local-Link Multicast Name Resolution.  The RFC for LLMNR (#4795) arose from a need for a way to get hosts communicating with each other on a small network with zero configuration.  As the name implies, it is only on the local link, so this is not a substitute for DNS, but rather a complementary system that will improve connectivity. The technology works with both IPv4 and IPv6 and is included and enabled by default on Windows Vista, Windows Server 2008/R2 and Windows 7.

This feature alone, is reason enough for me to recommend an upgrade to customers. I have set up several small networks now with Windows 7 boxes and they were able to communicate and share files within minutes of being attached to the network. Browsing by hostname was reliable and easy.  Anybody that has done the same thing on a small Windows XP network will be all too aware of how easily name resolution can be broken. The bottom line is that this technology will save companies money as it will surely reduce calls from end-users with connectivity issues.

So, how does all of this magic work? It is not all that difficult actually.

The standard is based on a standard DNS data packet, but it sends out a packet that can be up to 512 octets in size in multicast on port 5535. IPv4 hosts will listen for these broadcasts at 224.0.0.252 or in the case of of IPv6 at FF02:0:0:0:0:0:1:3 .  Hosts will then respond and this information will be cached for use by the operating system allowing for fast name resolution.

The LLMNR cache will only be queried for information if a DNS query fails, and as mentioned above it should not be considered the primary form of name resolution but rather a complementary one. If one were to set the LLMNR cache with a higher precedence than the DNS cache, it could be used (inappropriately) as the primary resolution mechanism.

LLMNR is currently unable to propagate across routers, but it is interesting that in the actual RFC for LLMNR, there is considerable discussion with regard to enabling this in a wider, perhaps Internet level, fashion.

In Server 2008 (and presumably Vista/Windows 7) LLMNR can be disabled. I am not quite sure why anyone would want or need to do this, but should you find reason here is a link that will show you how it is done.

Anyway, I realize that this post was a little deep on the technical side, but I just wanted to highlight and perhaps promote this technology so that more people will make the switch to our new beautiful suite of stable, reliable and secure operating systems.

Cheers!

NTBackup for Server 2008 with Exchange

As the exploding popularity of our “Running NtBackup under Windows 7” would suggest, the emergence of our latest and greatest operating systems has also left a few holes that Microsoft has yet to plug.  As our readers have seen from our first article, it is very easy to get NtBackup running under windows 7, but more and more people are also realizing that there is a significant need for this on their Server 2008 and Server 2008 R2 boxes that are running exchange.

Currently, Microsoft does not include any product that adequately backs up exchange server on these platforms. The biggest issue with all of the schemes is the fact that logs are not cleared and these servers end up with a lot of wasted space from these.

Honestly, I don’t know when Microsoft plans on addressing this issue officially, but given the screaming we have heard, I would hope that it is soon.

Anyway, to get NTBackup working for exchange in this scenario is almost identical to our Windows 7 tutorial with a couple of small exceptions.

The process goes like this:

Copying the following binaries from a server 2003 install (C:\Windows\System32\) to a new location such as (C:\Program Files\NTBackup\):

• ntbackup.exe
• ntmsapi.dll
• vssapi.dll

Then, install the removable storage manager in server 2008 which can be found under the features menu in server manager.

Finally, go into an older server and copy esebcli2.dll from your server (C:\Program Files\Exchsrvr\Bin) and put it into your new location which in our case would be (C:\Program Files\NTBackup\):

Then, change the esebcli2 reg key from (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\DLLPaths)

C:\Program Files\Micrsoft\Exchange Server\Bin\esebcli2.dll

to

C:\Program Files\NTBackup\esebcli2.dll.

Now go ahead and set up your exchange backup as a scheduled task just as you would have done in the past.

Please remember that this is more of a band-aid solution  and is totally unsupported by Microsoft. This will not work with tape drives, and it is very possible that future Microsoft service packs could break this functionality.  With that being said, it has been very solid in all of our testing thus far.

Cheers!

GPO Drive Mapping Issues

 

Apparently, mapping a drive using group policy and applied to a Windows Vista machine can result in users actually not being able to see their drives properly. While I won’t get into the reasons behind this too deeply, it is inherent in the security model that UAC relies on to function.

UAC breaks each successful logon into a split token with half of that being a standard user token and the other half being an elevated administrator token. When group policy maps drives, these are mapped under the elevated administrator token which results in the lower standard user token user being unable to see these drives as they have been theoretically mapped in a different session. 

Obviously, a simple fix would be to disable UAC, but anyone that is a loyal Slick IT reader knows our feelings on that.

The other solution is not entirely acceptable to me either as it could theoretically allow malware to redirect drive mappings, but for the time being it is the best fix we have.

Simply open regedit from the run line and modify the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

I am not sure whether this problem affects Windows 7 clients, but I would guess that it does given the closeness in the UAC architecture of both Vista and Windows 7. If anyone can confirm this issue exists, please comment below!

Hope this helps!

10 Great Windows 7 Tips

The faster you you get your hands on Windows 7, wean yourself off of XP, or rid yourself of Vista, the faster you will be able to get in on the great new productivity tools that Windows 7 offers. It has been a long time since the reasons to switch to a new Microsoft OS were compelling, but that time is here.

Here are 10 things that are going to make your computing experience in Windows 7 a lot better and I encourage you to give them a try!

1. Try out Windows XP mode.  We all have our favourite “old” programs that we don’t want to part with. It might be that great little utility that tracks your fitness routine or that neat little bridge building game. Honestly, most of these will work on Windows 7 using some form of the compatibility mode, but if they don’t – just install it in  virtual XP mode and it will be available from your Windows 7 start menu just as any installed program is. Check out Paul’s guide to setting this up here.

2. Open Command Prompt Here.  This used to be only available as a Windows XP Power Toy, but has been built-in to Windows 7.  Simply hold the the shift key and right click within a folder to get the option to open a command prompt at that location, shift and right click to add it to the properties menu, or type start into the command prompt window to open Explorer at that exact location – Slick!!!

3. Present Yourself!  Pushing the Windows key and P will bring up presentation mode, that will allow you to choose your screen setup and projector modes. This eliminates all of the vendor specific, inconsistent interfaces that we are all used to in Vista and Windows XP. Windows and the X key will open the mobility centre giving you further options.

4. Aero Snap Windows 7 offers a great way to quickly get windows out of the way. Selecting a window, pushing the Windows key and one of the four directional arrow keys will quickly snap the window to one side or the other to the top and bottom of the screen.

5. Burn ISOs.  I was sure that I would witness the parting of the dead sea before Windows actually included this feature, but I am now pleasantly surprised. Simply right clicking on an ISO file will give you the option to burn it to a cd with a simple, reliable interface. Gone are the days of having to hunt down a spyware-infected third party tool to work with ISO images.

6. Use search connectors. We have a great article on this feature here. This feature will allow you to search non-network resources from within your Windows 7 search box. Twitter, YouTube and many other sites are open search compatible and will allow you to do this.

7. Try the new calculator and paint.  These have been revamped in a big way and are now extremely versatile modern tools. One of the great features in the calculator is the ability to figure out the difference between two dates. Paint now saves files as a .png file by default which, for obvious reason, makes a lot of sense.

8. Make your VPN useful again. As documents such as PDFs started growing in size, the usefulness of the venerable VPN connection started to wane. While it is still the defacto tool of choice, no one can deny how slow and clogged up these connections inevitably become. The new BrancheCache feature should reduce the amount of WAN traffic significantly  through the use of intelligent caching of frequently used documents.  

9. Pin items to the taskbar.  Most items in Windows 7, including the control panel can be easily pinned to the taskbar. Simply open the control panel so that it’s icon sits in the taskbar and then right click on that icon and select pin to task bar to make this stick.

10. Record your problem and email it.  System administrators everywhere are going to love this feature. If a user is having trouble explaining an issue, and a screen shot just isn’t doing it any justice, simply fire up the Problem Steps Recorder.  This will allow the system administrator to see the steps that are needed to reproduce the problem and will allow for better analysis of software or hardware issues.  Simply search for PSR in the start menu to find this great little utility.

So there you have it folks… 10 ways to better leverage your computing experience into a productive experience.  Additional comments would be greatly appreciated.

Fixing Typical Boot Problems

No matter how good our beloved Windows operating system has become, one has to expect that occasional problems with the boot process will arise.  If you are a loyal Slick IT reader, you will have already read our article and made yourself a boot disk and already understand how the boot process works. Today, we are going to look into some common fixes for boot problems that IT techs everywhere are sure to have run into.

This article is applicable in some way shape or form to all versions of Windows, but primarily the information given here is for Windows Vista, Server 2008, Server 2008 R2 and Windows 7. These newer flavours of Windows have a modified boot process that has both advantages and some quirks as compared to the NT/XP flavoured boot.

The first one that is 100 specific to the New NT 6.0 and later kernel, is problems in the Boot Configuration Database (BCD). Typically, this issue presents itself with an error message like “Windows could not start because of a computer disk configuration problem”; “Check boot path and disk hardware”; or “Could not read from the selected boot disk.”

These error message most often come from the careless deletion of the BCD but can also occur from disk issues resulting in BCD corruption or the addition of a partition that has somehow changed the name of the volume.

To fix this, simply log in to the Windows Recovery Environment and run the following commands: bootrec /scanos and bootrec /rebuildbcd. You will also find that the bcdedit.exe tool has some other options availoable that may be of use.

Common to all versions of Windows starting with NT is the infamous “Missing Operating System”; “Invalid Partition Table”; or the “Error Loading Operating System”.

The cause is simple. Ninety-Nine per cent of the time this is due to corruption by due to hard disk errors. Viruses and poorly written device drivers may also be responsible for corruption of the Master Boot Record (MBR).

Fortunately, this is also the easiest of all of our boot problems to fix.  Simply  run bootrec /fixmbr from a boot disk or the Windows Recovery Environment.

Many of you have probably run into “BOOTMGR is missing”. This too, is a result of corruption and is equally easy to resolve. Simply running bootrec /fixboot should clear this up.

Our final cause of boot problems may often be the most serious.

When Windows is reporting that operating system files and/or xxx.dll is missing, you should immediately suspect disk issues.  This particular error may be indicative of many files missing and not just the one listed.

Often it is easier to just reinstall the OS, but if you are in the mood to try and recover from this, you will need to launch the Windows Recovery Environment and try to find the files needed on a Windows disk or in the \Windows\winsxs\backup folder. Or, failing that, try to find and copy the file from another running machine in your network – just ensure that it is from the same service pack and OS

These tips in unison should allow you to recover from almost all boot failures. If all else fails, go for the windows repair install and cross your fingers.

Hope these help.

Understanding Disks and Disk Management

Well, today’s post isn’t a fix per se. It isn’t even a tutorial, but I think that the information contained herein is invaluable for understanding disks and troubleshooting disk management issues.

A lot of us have a real rudimentary understanding of how disks and volumes are managed in Windows. Most of this comes from the overly simplistic and dumbed down models that we are given when studying for the A+ designation or it is an understanding that we gained long ago when FAT32 was the predominant file system in use.

A lot has changed since then, and I want to take you on the journey to understanding what is actually happening behind the Disk Management MMC.

So let’s begin at the root of disk management in modern versions of Windows. That swanky mmc that we all know and shown below is actually loaded through a Windows dll named dmdskmgr.dll. The functionality of this dll is simple. When it is loaded into memory it will in turn scan disks attached to the system looking for a LDM database. If it finds disks from the local computer, it will simply report the volumes that are present, however, if it happens to find an LDM from a foreigner computer it will then execute the import disk mgr which essentially just copies the foreign LDM and adds it to dmdskmgr.dll’s in memory copy of the database. Should you choose to import the disk, then it is essentially just committing the database write operation to the foreign disk which is actually done through a kernel mode dll called volmgrx.sys. Volmgrx.sys is actually the workhorse behind dmdskmgr.dll as it control the access to disk objects such as the LDM and the resident volumes.

Understanding this process alone goes a long way in troubleshooting why a disk might not be recognized or importable etc. While entirely out of the scope of this article, one could actually write a tool to manipulated the LDM itself and allow you to fix issues on a disk at a very low level.

Now, how does volmgrx.sys actually work. This is actually fairly straightforward in most cases.  Disks all contain disk relative offsets which are essentially a number of sectors from the start of a partition table to the actual partition itself.  The job of volmgrx.sys is to simply add the volume-relative offsets to the disk-relative offsets and allow the operating system to map I/O to the underlying partitions themselves.

On a multi-partition disk setup using spanned, mirrored, or some other flavour of RAID, thsi naturally becomes more complex. It is NTFS iself that allows us to create these types of volumes.

NTFS creates a bitmap file that can be added to or reduced at will. It is this file that tells the volmgrx.sys kernel mode dll where a logical volume begins and ends. Thus, to the OS itself the drive appears to be just a normal drive. In the days of FAT this was not possible as the whole partion table would have needed to be moved and thereby dislocating the data on one partition from the other. Then the volmgrx.sys will keep referring to the bitmap created to determine where free clusters are located and will logically write to these as necessary.

This process is virtually identical for all of the multi-partitioned types except for RAID 5 arrays where obviously the parity bit is also striped across the drives.

One last area that I would like to touch on is mirrored volumes. Some people have asked me why Windows cannot boot from spanned drives, Raid 5 arrays etc., but yet can boot from a mirrored volume which is a multi-partitioned volume.  The answer to this is simple. The Master Boot Record code sees the disk as one volume and only boots from half of the mirror which is marked as the boot volume.

Anyway, I hope this goes a long way toward helping you understand at a deeper level how Windows manages disks. I also want to give proper credit to Mark Russinovich et al. for the inspiration to write this article. Most of the material comes from his Windows Internals fifth edition book and I highly recommend this book for anyone who wants to understand Windows at a Engineering level.

Cheers.

Add printer to all profiles – Server 2008 Terminal Server

Profiles under terminal services can be really messy and problematic. Over the years, IT administrators have come up with various workarounds for profile issues under Windows Server 2003 Terminal Services.

Server 2008, unfortunately brings a few new challenges. I recently ran into one of these when I was asked to add a printer under a user’s profile to which I had no access.  Naturally, I just assumed that the old trick of making a shared network printer appear local would work. It doesn’t.

Server 2008’s add printer dialogue is very different from Server 2003 and many of the options that were available in 2003 are notably absent in 2008. Hmm….so how should I deal with this.

I could just add it to the login script, but this user only wants this printer to appear in this profile on the terminal server…so that’s not going to work. I thought about the issue for a while and then I remembered an old shell command that I had once used under XP to add a printer to all profiles at one. 

So, I fired up the command prompt, put in the command and much to my delight it worked.

Here it is…..

Rundll32 printui.dll,PrintUIEntry /ga /c\\localcomputername /n\\servername\printername

The solution is wonderfully simple and can be executed with very little effort – this is exactly what Slick IT should be.

Alternate Port for RDP

This is going to be short and sweet!

Often, smaller networks use RDP as their primary method of remote administration. This is really great if you are using one of Microsoft’s SBS servers because the Remote Web Workplace wizard will automatically add all clients and allow easy access through a website harnessing the power of TSWEB.

But what if you just have a few machines behind a firewall and would like to be able to RDP into all of them? The answer is simple – change the port that RDP listens on on the client OS.

RDP by default listens on 3389. I find 3390 and 3391 are always good alternate choices that are almost never used by any other applications. You can use any port you like if it is free, however.

Simply open regedit32 (this is accomplished by typing regedit on the command prompt or in the run box).

Migrate to the following key:

HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ TerminalServer\ WinStations\ RDP-Tcp\ PortNumber

On the Edit menu, click Modify, click Decimal, type the new port number, and
then click OK.

Exit out of the registry editor.

Now, go ahead and forward your firewall to pass that port through to the IP address of the client you have modified.   (Note:often routers will enable you to port forward external ports to different internal ports – this is equally effective and means that these registry changes would be unnecessary. There are many reasons for changing ports – use your best judgement)

Test it by using telnet.

For example: telnet mail.examplecompany.com:3391

You will know if it has connected if your cursor just starts blinking in a blank window and doesn’t display any error message.

Now, when you want to connect, use your RDP client and append your new port number to the address like below.

It’s that simple.  I know a lot of you out there will find this extraordinarily useful…and oh yeah, by the way…standard disclaimer applies when working with the registry: back it up first, we bear no responsibility in you making a mess of it.

Cheers….

Troubleshooting Windows Firewall

Firewall: The name says it all – this little piece of software (or hardware as it may be) is designed to keep your computer and the fires outside at some distance from each other.  It is an essential service, yet the eagerness of some to let the fires inside and burn their houses down is not unappreciated.

Let’s face it – firewalls can be a real pain in the butt and the one that comes with windows is sometimes nearly unbearable. I know a lot of you out there are tempted to live with this particular warning message forever…..

I know I certainly have, but actually the windows firewall is very easy to work with. Let’s discuss some ways that we can make this work for you.

Now first and foremost, any configuration you do to Windows firewall should be done through the firewall wizard itself. This often grabs any exceptions that are needed and most of the time will actually pre-emptively warn you when Windows firewall is blocking out something important. Don’t ignore these messages when they pop up – think about what they mean and either allow or ignore as you see fit.  This will save you a lot of time.

Now, after you have tried forwardding ports as they appeared in the wizard/notification area and have failed in making the troublesome service or application work, the second step is to enable logging on the Windows firewall. Far too many people take a non-logical approach to troubleshooting firewall issues and basically just start clicking randomly allowing and denying until their issue is magically solved. Unfortunately, they have also magically opened up numerous attack surfaces on their machine and by two am the next day an army of botnets has already been able to compromise their machine and they are inadvertently relaying thousands of Cialis ads per day…this definitely puts one in between a rock and a hard place.  The moral of the story here is simple: AVOID THE IMPULSE TO RANDOMLY DISABLE/FORWARD PORTS IN WINDOWS FIREWALL. Troubleshoot these systematically.

Here’s how to enable logging:

1. Open the Windows Firewall with Advance Security snap-in, right click on the firewall and choose properties.

2. Select the profile you wish to troubleshoot.

3. In the logging group, click on customize.

4. More often than not, you will be looking for dropped packets as these are the data packets that windows firewall has rejected and are probably the reason why that undocumented and proprietary software package you are trying to make work is failing. Click on yes for the dropped packets. Or, conversely, click on Yes to monitor which packets windows firewall is allowing through.

5. Click OK to apply the settings. As you can see above, the log files are kept in the system32\logFiles directory.

Now try to recreate the problem and see if Windows firewall is in fact the culprit. You will want to disable the logging after you are done with it though, as there is a considerable performance hit associated with this as the log only stores the last 4 KB of data.

Now there is one other tool that is often overlooked in tracking down port forwarding issues.

The simple netstat command when used with the –a and –b switches is a powerful tool in tracking down applications that require access to the machine or in the case of spyware blocked.

Netstat when used in this fashion will allow you to see what services and/or processes are listening for incoming packets.  This, combined with a tool like process explorer by Sysinternals, is extremely useful in quickly figuring out access requirements.

With all of these tools at your disposal, there is no reason to completely disable a firewall again nor will you be forced to just click aimlessly and randomly in the firewall configuration.

Enjoy!

Self-Healing NTFS

In the past, inconsistencies on disks could mean hours of trouble. Usually, the disk would have to be taken offline and a tool such as check disk would have to be run to correct the errors.

While check disk actually works very well at marking sectors as bad, it is slow and inconvenient. Windows engineers recognized this limitation and came up with a fairly robust solution: Self-healing NTFS.

Windows Vista, Server 2008 and Windows 7 all utilize this new feature. The process is actually very similar to how check disk itself works, but with a difference. Most disk corruption will tend to occur in one area of a file and is not generally endemic to the disk. That being the case, self-healing NTFS systems will actually detect corrupt areas on the disk, prevent access to it, and spawn a worker process that will take check-disk like corrective actions on the disk.  This greatly minimizes disruption to end users especially on a particularly busy file server.

This tool is not a black box, luckily and we can actually get in and control its behaviour.

The fsutil repair set command can be used to both view the status of the self healing feature and to set its parameters.

 

Note, you will have to run this as an administrator to get it to function.

Some useful flags that can be set on the volume are:

 

SET_REPAIR_ENABLED – This simply enables self healing on the volume in its default state.

SET_REPAIR_WARN_ABOUT_DATA_LOSS – If the self healing option is unable to fully recover a file, it will visually warn the user about the potential data loss.

SET_REPAIR_DISABLED_AND_BUGCHECK_ON_CORRUPTION – This option would mainly be used by system engineers trying to pin point when corruption is occurring. This flag will actually create a 0X24 stop error which will be cleared during reboot.

Should you wish to initiate a manual self-healing operation, this is available too. Simply run:

fsutil repair initiate  - to start the process and fsutil repair wait commands.  After you are done, go ahead and query the status of the volume by running

fsutil repair query <volume name>

Pretty neat stuff here. I suspect that this will be used often as an alternative to running check disk as more and more people learn about the powerful features of this tool.

Cheers…….

Rearm Server 2008

Today’s topic will be brief, but it is of interest lot of IT professionals out there that need to work with evaluation versions of Server 2008 for testing and self-learning.

As most of us know, when we download an evaluation version of Windows Server 2008 off of Microsoft’s site, we are given a 60 trial version that functions wholly intact.  If you have received an evaluation DVD with an MS Press book, chances are you will be granted 120 days on the first activation. But this actually isn’t the end of the road for these. They can be, as Microsoft has coined it, rearmed.

The tool you need is the Soft Licence Manager, and it can be invoked by typing in slmgr.vbs in an elevated command prompt. Using this tool, you will actually be able to rearm the activation 3 times, bringing your total evaluation period to 240 days – quite a generous allowance really. Let’s look at some of the switches.

So, slmmgr.vbs /dli

This first switch will display all of the licence information.

slmgr.vbs /ato

This switch can be used to activate windows.

slmgr.vbs /rearm

As the switch implies, this will rearm the OS allowing you another 60 days.

slmgr /ipk <product key>

This may in fact be one of the handies switches if you are switching between versions of server 2008. It can be used to replace the current product key with the new one inputted.

slmgr /xpr

Is used to find out the expiration of the current licence information.

There are also a plethora of advanced commands available, and I suggest that you check these out by running the standard /? switch to view these. Also, as with most things, all of these switches will work with Windows 7.

Enjoy your extended evaluation period!

Deploy anything through a GPO

As system administrators, we have all been there. You’ve just stumbled across some new great utility that will make your users life so much easier, you go to your group policy editor, set up the policy, and download the file only to discover that this wonderful utility is only available as a .exe file.

Unfortunately, software deployment through a GPO requires that the file be in an MSI. I have been personally thwarted by this many times and through this my lofty plans suddenly abandoned. Options do exist, however, and today I want to take you through a great freeware product for creating an MSI out of an .exe.

Our magic tool is produced by Caphyon and is suitably named Advanced installer and can be downloaded here. It truly is one of the best freeware utilities I have ever seen and will be enormously useful to any system administrator out there looking after a medium to large sized network.

So, one of my most popular projects is to customize and RDP client and then deploy it to the organization. There are a lot of tweaks that can be applied and it can minimize a terminal server operator’s headache by 100 per cent seconds after deployment. 

So you have gone through the steps needed to produce a customized RDP client and it is time to package it up. You now have two files that will have to be pushed out. These are mstsc.exe and mstscax.dll.

Create a folder on your desktop and drop these two files inside. Fire up advanced installer and select “New Project”

Select the simple project for this.

Once the Wizard fires up, choose and enter both a application name and a company name. The final product will install into a directory like so: Program Files\MyCompany\ApplicationName

OK, now click next and select the folder that you have created on your desktop. Click on next and select where you would like shortcuts placed. These can either be on your desktop or on the start menu or both.

Click next and select Finish. The project will then build itself into an MSI.  However, if you want to get fancy and add an icon to your project, untick the check box labelled “build now”  and click finish.

Now, simply click on the project details on the left hand side of the window and click on the browse button for icons.

Select any icon you like, click on the project menu and then select build. The project will build your MSI with an icon to be easily deployed.

Go ahead and finish setting up tour GPO, and deploy to your workstations.

Slick IT is……

Enjoy!

UAC – Configuring Run Levels

 

As promised, here is the second and what I hope to be the most useful part of my series on UAC. A lot of this control is in fact on the development end of the application and good programming techniques actually help eliminate the need for UAC to even prompt for elevation. But, there are, of course, a certain number of operations that will need to be elevated no matter how well they are written. The following should help[ you manage these.

Applications running with an administrator access token will run in elevated mode by default, but often you will want to run an application with a standard user token in elevated mode. One of the most common uses of this would be to run and/or test scripts in a command prompt window.

To do this only once, simply right click on the programs shortcut icon or on the executable directly and select run as administrator.  You will be prompted for consent before continuing. As mentioned, this is a one time deal and windows will not remember this action.

Should you need an application to always run with administrator privileges, Server 2008 also allows users to mark a program to always run as an administrator.  To do this, simply right click on the program, choose properties, select the compatibility tab and under the privilege level section select “Run this program as an administrator.”  You will find that this is extremely useful for legacy applications that need administrative privileges to run and is also a good place to start troubleshooting when trying to figure out why legacy programs aren’t behaving properly in the Windows Server 2008 environment.

 

Anyway, these little tips help those of you just embarking on the Windows 7, Server 2008, and Windows Vista experience.

I believe Paul is planning on writing a blog post on creating UAC application manifests, so stay tuned for that.

UAC and Application Run Levels

Whelp, here I again find myself having to apologize for the lack of updates on the site recently. Unfortunately, last week I actually broke my ankle and really broke it good. Generally, one should try and stay out of the path of deer jumping onto the road when riding a motorcycle, but I unfortunately decided to occupy the same space in time and place as Bambi  and am now hobbling around on crutches. Anyway, I am fine now and ready to start knocking some updates out for everyone!

With Windows Vista, Windows Server 2008, and now Windows 7 we have seen the introduction of User Access Control (UAC). While this may be the source of a lot of disdain, causing some people to even go so far as outright shutting it off, its importance in the new Windows security regime and architecture cannot be understated. Frankly, shutting it off is silly and will greatly reduce the ability off the OS to fend off malware, spyware,  viruses and worms.  

The whole concept, however, has been muddled by misinformation and is widely misunderstood leaving users completely bewildered when programs mysteriously refuse to work and produce cryptic error messages. For administrators of the `New`OSes (hereinafter referred to collectively as Server 2008,) a thorough understanding of this system is absolutely crucial to keep everything up and running.

In legacy versions of windows, all security functions were encompassed by the user groups themselves and access levels were determined by membership in these groups. Should a person want to slightly reduce administrative authority, the Power Users group was often chosen for this purpose.  In Server 2008, the use of this group is completely unnecessary and it is only kept around for maintaining legacy application compatibility.

Server 2008 is a very different animal. Now, at least in Server 2008 compliant applications, the application manifest itself will define the applications access privileges as RunAsInvoker, RunAsHighest, and RunAsAdmin.

RunAsInvoker: This level results in the application running with the same privileges as the user.  In fact, any user can run the application, but no matter what group they belong to, even if they are in the Administrators group, the program will only run with a standard access token. This concept becomes really important when you get into the windows integrity levels as this fact can cause a program not to function as intended even if run by an administrator. In fact, the only way to get programs that are of the RunAsInvoker type to run as an administrator is to get the parent process running the program to have and administrator access token. This generally means opening up a right clicking on and opening a command prompt window as an administrator. I have heard many people proclaim, when they are told this little fact, that they are “already an administrator” and have watched them click and run a program endlessly without success until they actually run it in an elevated command prompt at which point it magically works.

RunAsHighest: As the name suggests, this runs the application with the highest privileges of the user. Boith standard users and administrators alike, may run the program, but certain program features may not be available based on access privileges. For example, members of the Backup Operators group will be granted fewer rights that an Administrator. Obviously, those who are part of the administrators group will run the program with a full access token.

RunAsAdmin: Only administrators can run programs that have been defined in their manifest as RunAsAdmin type. However, if users can provide Administrator credentials to allow the program to be elevated, or if the program is started from a previously elevated process such as the command prompt it will still run.  This type of program will always run with and Administrator access token.

As well as these run levels, Windows Server 2008 also protects application processes by using integrity levels. All processes in the OS are assigned an integrity level and process with a lower integrity are not allowed to modify those of higher integrity. Internet Explorer, for example, is assigned a fairly low integrity level making it a lot more difficult for it to compromise the OS. As well, the OS will identify the publisher of any program that tried to RunAsAdmin and the OS will flag the potential risk using Red and Yellow colour codes.  Red indicates that the program is from a blocked publisher and there is very likely danger associated with the install.  Yellow signifies “unknown” and Blue/Green are for administrative elevation for server maintenance.

A lot of people ask me how UAC stops malware from entering a system. They seem to feel that malware can easily circumvent this feature. While it is entirely possible that there are ways around it, all of the newer OSes that have UAC are much more difficult to penetrate.  The elevation prompt itself cannot be spoofed and Windows has some very sophisticated algorithms in place to detect any kind of software install in process, which would then trip the UAC elevation prompt. Only Windows Core services is able to bring the elevation prompt up -which, as I have stated, makes it extremely difficult to get around.  UAC is a good thing and I hope that after reading this you will agree.

For all of you developers out there, here is a good little power point on UAC from Microsoft and it outlines some of the design considerations in making a nice UAC compliant app. Give it a whirl, it is obviously in much greater detail than what I have here and an interesting read.

User Account Control- How to Make a Good UAC Application

Next post, I will go over some easy ways of controlling the run levels for all of you server admins out there, and little tricks that can make your life easier.  I hope that all of you are now migrating back into your OS and re-enabling UAC now……

Cheers……

Next Generation TCP/IP Stack

Undoubtedly, one of the biggest sources of complaints from adopters of Vista and Server 2008 has been the new Networking UI and some of the shit that goes along with it. Yes, even I, have sat staring dumbfounded drooling incessantly as  Vista seemingly takes over and “Network Awareness” tells you that your perfectly configured router is incapable of accessing the internet or you are totally unable to even browse network shares on computers around you. WHY>>>AAARGH!!!!

The frustration, the agony, and the eventual exorcism and sacrifice of the Vista Demon that has brought unspeakable amounts of suffering to you and the pane-glass living room sporting a perfect IBM-sized hole are immeasurable. But wait, why would Microsoft do this, surely there is some reason, right?

Unfortunately, for many of us, that answer for the time being may be “No.” There isn’t a lot of apparent usefulness. But, that doesn’t mean that there aren’t any improvements at a lower level actually making the OS work better…in fact there really are (really, I’m not bullshittin ya!). Microsoft, as usual, has done a really terrible job in showing the average user why they should care about any of these configuration options – but for the IT professional- some of these changes DEFINITELY bring increased reliability and lower TCO (Total Cost of Ownership). 

Vista and Server 2008 have a completely re-written TCP/IP stack that is now referred to as the Next Generation TCP/IP stack. It replaces the venerable, well-known, but buggy standard Windows TCP/IP stack that was basically unchanged since the Windows 95 days. Let’s face it, with the role that TCP/IP has assumed in modern computing, and the demands that have been placed on this protocol suite, it is no wonder that the Microsoft Engineers wanted to tackle this one. Undeniably, nobody imagined that this 70s era protocol would be robust enough and able to keep up with streaming media, VOIP, and the massive routing that packets are forced to go through nowadays. It is the next generation TCP/IP stack that makes it all work just a little better.

One thing I want to say now. DO NOT DISABLE IPV6 IN ANY PRODUCTION SERVER. THE RESULTS CAN BE CATASTROPHIC! (This one is for you Devon) I don’t say this out of personal experience, but my fellow colleague can vouch for it!  With that little not-so-casual warning out of the way…Let’s jump into this.

The changes in the TCP/IP stack not only apply to IPV6, but also apply to our trusted friend IPv4.

Here are some of the changes:

Modified Fast Recovery Algorithm

This feature provides the ability for windows to alter the way in which a sender can increase the sending rate if multiple segments in a data window are lost and the receiver has acknowledged the partial data receipt.  The end result here is greater reliability and speed.

Network Diagnostics Framework

Provides a framework within the stack that can help users recover from networking errors and troubleshoot networking issues. Often, to understand the information this framework present still requires a thorough understanding of networking in general.

Compound TCP 

This is an optimization that is able to increase the amount of data sent in a connection without adversely affecting other TCP/IP sessions.  This often does produce a noticeable speed increase.

Automatic Black Hole Router Detection

This particular enhancement is hugely useful in network segments that have lossy routers and general patchiness. This actually forces TCP connections to not terminate when an intermediate router is silently discarding large TCP segments and will force the connection to stay alive even when error messages and retransmissions occur. The end result here is reliability.

Automatic Dead Gateway Retry 

Similar to above, except that it will actually periodically try to contact and unreachable gateway and will start utilizing it once it is alive. This, too, adds to the overall reliability of a TCP network.

Spurious Retransmission Timeout Detection

Offers correction for sudden increases in retransmission timeouts and prevents unnecessary retransmission of segments. This can have a huge impact on speed in an environment with some unstable routing equipment.

The following apply to IPv6 only.

 

Link-Local Multicast Name Resoulution

At some point in time, this little feature is going to become hugely useful –especially for the technically challenged setting up a Vista or Server 2008 home network.  This little feature will actually allow IPv6 clients to be able to resolve host names without a DNS server provided that the hosts are all on one single subnet.  This will greatly increase reliability, especially in small business environments.

 

Random Interface IDs

This feature helps thwart scanning attacks based on Networking equipment manufacturers company IDs Basically, it generates random interface IDs for auto-configured connections including public and link-local addresses.

 

This list is by no means an exhaustive one, but I hope that it helps highlight some of the strides forward that Microsoft has taken in developing this stack.  While we all hate change, at some point in time we WILL all be using IPv6, so why not get ahead of the curve now and learn how to leverage this technology into grater performance for your IT environment. Change is inevitable, it brings some pain, but 5 years from now we will all be reaping the benefits of our highly robust computing platforms.

Server2008 networking is a giant leap forward, so get your game shoes on and save yourself the cost of a new window!

Server 2008 Boot Process – Making a boot disk.

Today’s topic is something that virtually nobody has paid any attention to with both Vista and Server 2008, yet the assumptions behind not investigating the very way both Vista and Server 2008 boot will undoubtedly have catastrophic ramifications for some poor tech somewhere.

While not well known, the whole process in which server 2008 boots is dramatically different from previous versions of Windows. Moreover, it is precisely these differences that make it so critical to know how to make a proper boot disk for Server 2008 and know where to start troubleshooting when your server just sits there and taunts you with flashing lights and spinning fans with Windows nowhere to be found.

The classic Windows NT boot process is well known and goes like this.

1. You power on the machine which then goes to the startup BIOS.

2. The Start up Bios loads and performs the Power On Self Test (Post)

3. The startup bios loads the Master Boot Recod of the active partition which then loads up the partition boot record.

4. The boot sector loads NTLDR which then loads the following.

boot.ini

ntdetect.com

ntoskrnl.exe

system registry hive

device drivers

hal.dll

At this point, if all has gone well, you will now be looking at a running Windows NT, XP, Server 2003 machine.

In server 2008, instead of loading NTLDR a new file called bootmgr exists.

Bootmgr then rus the following

Boot Configuration Database (BCD)

Winload.exe

ntoskrnl.exe

system registry hive

device drivers

hal.dll

Then bootmgr passes control to ntoskrnl.exe and the boot sequence is complete.

As can be clearly seen, the traditional boot disk files are of no use in server 2008 as the machine boots in a completely different fashion. Furthermore, when a boot disk is made, it is unique to the server 2008 box it was made for as the BCD file needed for the boot disk contains a system GUID that must match the system upon which it is booting.

Making a boot disk is accomplished in the following fashion.

1. Format a floppy in your Server 2008/Vista machine using the quick option.

2. Open a command prompt with elevated privileges and run the following lines.

MKDIR A:\BOOT

XCOPY /H C:\bootmgr A:\

REG SAVE HKLM\BCD00000000 A:\BOOT\BCD

With this, you have now created the file structure needed for a server 2008 boot disk, and have also copied the files needed for boot.  You will notice that copying the C:\Boot\BCD files directly to disk will fail as these are actually loaded as hives in the registry and locked.  The hive that they reside in HKLM\BCD00000000 is a hidden registry key and cannot be seen from within regedit.exe.

After creating your boot disk, I would “highly” suggest that you test it once or twice, label it and put it away somewhere safe for “a rainy day”.

 

Cheers!  

SQL Server 2008: Self-Destructing Databases

Using SQL Server 2008?  There’s a little something you should know about to avoid losing data.  Earlier, I wrote:

Certain previously-innocent actions create new (often empty) database files, without warning, and (by default) in the Program Files folder.  If you lose these files, your database goes straight to the bit bucket.  So, if you attach your 15GB database by copying the .MDF and .LDF files, enable full-text indexing, detach your database, and take your 15GB home with you, you’re now the proud owner of 15 GB of uselessness.  Your database is gone forever because you didn’t also grab that 2 KB file SQL Server generated automatically and placed in your Program Files folder.  Whoops.

Well, here’s a bit more detail.

When working with databases in SQL Server 2008, it’s very easy to unknowingly create additional database files.  A great example of this is working with full-text indexing.  In SQL Server 2005, full-text indexes were saved outside of the standard database files, in a separate directory.  Losing this directory wasn’t too big a deal, because re-indexing a database is usually a trivial process.  Even if the full-text files were lost, it was easy to restore or attach the database itself and then recreate the full-text index.

In SQL Server 2008, full-text indexes are now stored in the database itself.  This is a great improvement for managing databases; it means the full-text index is part of the actual database itself, and is included in backups.  Wonderful!  The only problem is that the index is actually placed in a separate data file.  SQL Server experts fully understand that one SQL Server database can contain several database files; there are lots of great reasons for doing this.  In fact, putting the full-text data in a separate file is probably a good architectural decision.  But people working with more simple SQL Server deployments might not realize this.  To these people, a SQL Server database consists of an .MDF file (the data), an .LDF file (the log), and perhaps an extra folder of full-text data.  The only file that was really needed to save or copy the database was the .MDF file; the log and full-text index could easily be recreated.  Now, though, the database file containing the full-text index will be in a separate .NDF file, placed by default in the Program Files folder, and the primary .MDF file is entirely useless without this new .NDF file.

So, what’s the point of all this?  Know the following:

• Before copying a SQL Server 2008 database’s files, make sure you know exactly which files are used to store the database, and make sure you copy all of them.
• Making an SQL Server backup, copying the backup file, and restoring from this backup is a much safer way of saving and moving databases.
• Now, more than ever, it’s important to specify locations for all database files.  Program Files is not a good place to be saving data.

Overall, this is a good change, but you really have to know what’s going on.  There’s nothing complicated here, but if you’re not aware of these changes, they can easily catch you by surprise.

What did it do?

The registry – that dumping ground for Windows software developers and the nesting grounds of so many malware packages out there. At times, it may seem hopelessly cluttered and virtually unintelligible, especially if you are trying to actually figure out what has gone wrong deep within and why your production server refuses to boot after uninstalling AVG or some other equally well-written software package.

But don’t despair, in server 2008, troubleshooting the registry is actually fairly simple – especially if you have performed due diligence and exported the registry file before the change.  In fact, it is very easy to compare two registry files and visually see the changes that have been made using the venerable File Comparison Tool (fc.exe).

This is especially handy in test environments where you may have several VMs set up with the identical copies of Server 2008 and want to see the effects of several different versions of a software package under review.

Let’s take a look at how to use this tool….

So, the first step is to export the unaltered registry. There are several ways this can be accomplished, but the hands-down fastest way of dumping this to a file is to do it from the command line.  It isn’t strictly necessary to run with elevated privileges to perform this, but I find that often this prevents a lot of unpredictable results, so I have made it a bit of a habit.

Here’s the command:  regedit /e <path with file name> 

For instance, if you want to create a file called  pre-shitty-av-install.reg on your C: drive your command would look like this:

 regedit /e C:\pre-shitty-av-install.reg 

Now go ahead and install or make the changes to the system that you are curious about and immediately afterward export the registry in the same fashion as above with your new file name.  For example:

regedit /e C:\post-shitty-av-install.reg  

Now, simply run the File Comparison Tool (fc.exe) and pipe the output to a text file for easy reading.  The command that we would use is

fc /u pre-shitty-av-install.reg post-shitty-av-install.reg > changes.txt 

Simply open the file in notepad, and you will see exactly what changes were made in the registry and how they might be affecting your Windows Server 2008 box.  Easy, simple and extremely useful….enjoy!