Archive for the ‘Windows 2008 Server’ Category


I have often wanted to vary the backup schedule for Windows Backup, but the user interface only offered once a day or more than once a day.  I wanted it to happen not every day, and I finally discovered there was a way.

To get more options, you need to use Task Scheduler, which can be found under Administrative Tools in Control Panel.  When it opens, navigate to Microsoft->Windows-Backup.  You will see the schedule you set up in Windows Backup.  Highlight the schedule, right click and choose Properties.  Then click on the Trigges tab, and finally click on Edit.

When you select Weekly, you now have the option of choosing only certain days of the week instead of every day.  Or select monthly and see

Now you can choose days of the month.

There are more options on the other tabs to help you set the way the Backup task runs.  I hope this has greatly extended how you use Windows Backup

Advertisements

Strange Behavior

I first noticed this for a client who had to reboot their server during the middle of the day.  Suddenly, a server that was running just fine, was no longer “visible” to client machines.  They could not connect to shares, could not ping the server, and were seemingly disconnected.  What was even stranger was that the server had no difficulties “seeing” those client machines.  Moreover, I was unable to remote desktop into the server from anywhere.

When I finally got on the computer, I looked at Network and Sharing Center and was shocked to see that the network connection showed Public and the network identification was for an unknown network.  How did that happen, and how could I make that go away?

What Didn’t Work

I tried restarting the server, restarting the router, restarting the switch, restarting the client machines all to no avail.  Then I hit on this:

The Solution

I opened Services and scrolled down to Network Location Awareness.  It was running, but it was set to start automatically.  I changed that to Automatic – Delayed Start, then restarted the service.

Voila.  The network went back to Domain with proper identification and suddenly everybody and everything on the network was connected again.

Seems as though the service did not have enough time to detect the network and set it properly.  I wish I had a great answer for why this starting happening, but I don’t as of yet.  Just happy that the fix was easy and hope it helps you at some point.  Actually I hope it doesn’t which means you don’t have the problem.

I have seen this on one and only one server. It was a 2012 R2, but I have subsequently seen the issue reported (but not solved) for 2008 R2 as well.


What Scares Me About Migrations

It’s always a bit scary doing migrations.  First, there is a lot of prep work to do that is designed to put your SBS 2003 or 2008 server in a state that is receptive to the migration processes.  Then there is – at least for me – two more scary moments.

  1. Will the information in the Answer File prove correct and sufficient for the migration to get started?
  2. Once the migration is finished and the destination server is being restarted, will it show errors or will there be a successful migration?

I have been disappointed as each of these scenarios have arisen.  I will address the second one in a subsequent post, but let me share with you a recent heart-stopping encounter with the first and how to fix it.

Finding the Source Server

In the answer file, you must provide among other things:

  • Source server name
  • Source server IP address
  • Source server domain name
  • Destination server name
  • Destination server IP address

Why wouldn’t migration not find the source server and how can you fix it? What migration has done by this point is established a good base in the destination server for it to operate.  For the network IPv4 properties of the network connection, they should be set so that:

  • IP address is what you provided for the destination server in the answer file
  • First DNS server is the IP address of the destination server
  • Second DNS server is the IP address of the source server

Toss in the source server name and domain, and you should be all set for a DNS query to properly resolve into an IP address.  It is my assumption that migration doesn’t rely on the  IP address you provide for the source as it wants to make certain DNS queries work.  Or maybe not as you will see.  Because even when all this is correct, migration continues to give you an error that it can’t find the source server.

Getting Access to the  Destination Server while in Migration Mode

Make no mistake about it.  When you get to migration mode, you have a working SBS2011 server below it, although not fully configured for the domain.  But how do you get to features and functions?

Pretty simply, actually.  While the migration wizard is in progress, just press SHFT+F10.  That will launch a command window.  From there, you can run command line executables to launch GUI objects.

Here is a short list you might likely need:

  • control.exe – launches Control Panel
  • services.exe – launches Services
  • control.exe /name Microsoft.NetworkAndSharingCenter – straight to Network and Sharing Center
  • taskmgr.exe – launches Task Manager
  • mmc.exe – Launches Microsoft Management Console

From these, you can get to an awful lot of Windows features.

But What About Not Finding Source Server?

I checked the network settings and they all looked fine.  I checked the DNS on the source server and it had the right values.  Stumped, I decided to make an end run.

The first thing was to get access to the hosts file.  I find the simpliest way is to use Notepad, so at the command prompt, type notepad.exe and press enter.  Then open the hosts file (remember to change file type from .txt to all files) in the path c:\windows\system32\drivers\etc:

Openng hosts file

The thought was to add the source server to the hosts file so migration might find it when DNS did not seem to.  I added the source server as shown here (your IP address ad server name should match the source server).

Modifying hosts file

Just be sure your destination server is set to use hosts.

  1. Open Network and Sharing Center as described earlier.
  2. Click on Change Adapter Settings.
  3. Right-click on the network and choose properties.
  4. Scroll down to IPv4 to highlight and click propertes.
  5. Click on the WINS tab.
  6. Verify your settings match the following, then click OK twice and close Network and Sharing Center.
  7. Click NEXT in the migration wizard, and it gets past the source server issue.

WINS settings


The symptoms were a little strange. Some users were being prompted for a password when using Outlook, but others were not. Our checklist to solve the problem included:

  • Making sure user name entered as domain\user.
  • Uninstalling and reinstalling Outlook (a lot of users running old XP machines and Office 2007).
  • Creating a new profile.

None of these whack-at-it things worked, of course.  So I started getting more information.  The first thing I did was to get an authoritative list of those who had the problem.  It was then the pattern jumped out at me.  It was all users except those in admin group.

I then ran some tests using https://www.testexchangeconnectivity.com/ so I could see what was happening. Before I tell you about that, let me give you some additional background about this server.

Accidentally, one of the users made a mistake trying to set up a new SharePoint web site, and as a result almost everything in Default Web Site and SharePoint got damaged from a little to completely dead.  Some permission issues cleaned up most of the Default Web Site, but SharePoint had to be rebuilt.  That was successful, albeit it very messy, and everthing seemed fine.

Back to the connectivity tests.  What I found was that everything was working just fine.  I couldn’t get an error to show up.  Until I switched from the network admin account to a user account.  Hmm, I thought, maybe I don’t have the right credentials.  So I created a new account, tried that, and it also failed when testing Outlook for RPC over HTTP.  For grins, I changed the role on the new account to admin, tried the test again, and it worked.  Okay, that confirmed it was membership in the admin group.

The test goes to the directory C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover and in particular to autodiscover.xml in that directory.  I checked permissions on that directory and found that the network administrator account had rights, but that authenticated users was missing.  I added authentic users to the group, and it automatically gave read & execute, list folder contents, read, as the correct permissions.

Feeling pretty proud of myself, I ran the connectivty tests again.  To my absolute surprise, they failed as before.  I was frustrated, and it was late in the evening, so I put it aside. I was just about to fall asleep when I jumped up, grabbed my laptop, and logged back onto the server.

I opened command prompt to run as administrator, ran iisreset, then tried the test again.  Voila!  It worked again for standard users.

Hard to tell when this may likely happen to you, but if it does, I hope this saves you a lot of time.


In the application event log, event ID 13042 was being posted from Windows Sever Update Services and the message Self-Update is not working.  Here is at least one solution for why this was happening and how to determine if this is your problem.

Open a browser and type the url as http://<WSUS_Server_Name>/iuident.cab.  If you get a file not found error or something similar in your browser, this is probably for you.  If you get a file download dialogue box, first click on cancel and assume this solution is not for your problem.

If you got the file not found or similar error, then here is what you should do.

  1. Open IIS Manager.
  2. Expand the tree for the SBS Server then for Sites.
  3. Click on Default Web Site to highlight it.
  4. Click on bindings in the action pane.
  5. Make sure that there is an entry for http on Port 80 with * as the IP address.

If the entry points to another port or isn’t there, you probably have to make some other adjustments in IIS.  Here is what I think you may find.

Perhaps you have added a new site that you want to host and have given it Port 80, changing the default web site to another port, like 8080.  This would would allow normal Port 80 traffic to the new web site, but would also prevent the default web site from starting because of a port conflict.  The easy solution is to change the default port to say 8080, or some other unused port.

While you could change the physical path for the default web site to the directory you want for your new web site, another way is to do the following.

For bindings, create to entries.  Suppose the external URL is mywebsite.com.  Then create two http bindings, both for port 80 with * as the IP Address.  Use http://www.mywebsite.com as one host name and mywebsite.com as the other host name.  This will direct traffic to the specific web site on port 80 rather than the default traffic.  If you host multiple web sites, do the same thing for each.

This should make the 13042 error go away.

To verify, open command prompt as administrator.  Go to c:\Program Files\Update Services\Tools and run this command:

wsusutil checkhealth

Then open the event viewer, application logs and see if you now get a 13040 Self-update is working event.


Now that you have the basics of how to create a volume on an iSCSI target and mount it for use, let’s explore some reasons for doing so.

Server Storage

The simplest case I will present is a single SBS server.  There are several important data stores for SBS:

  • Exchange Server
  • SharePoint
  • Shared folders
  • LOB or other data that is used by SBS members

When you first install SBS, these are all going to be located on the OS drive.  Using the SBS console, you can migrate them to another drive location.  In the case of LOB data, which is set up independently, you no doubt can chose the drive on which to locate it.

You could start with disks installed on the server in a traditional fashion.  Maybe the drives are 500GB, 1TB, or larger drives.  Your Exchange requirements might be modest, say 15GB.  You estimate that SharePoint files are likely to grow to 20GB in the next six months to a year.  Shared folders might start at 20GB but could go up or down depending on what migrates to SharePoint, for example, and what other growth you anticipate.

You can use one drive for Exchange, one for SharePoint, one for shared folders, and one for LOB data.  But perhaps your server can’t accommodate that many drives.  And it certainly might not accommodate them as RAID 5 or 6 volumes and be independent of each other.  What are the choices?  Well, you could  use one physical disk, no RAID, and create several volumes and use different ones for different data types.  Or perhaps use several drives to create a RAID set and and allocate volumes on it.

Now that you have several volumes on your drive or drive array, sized to accommodate the data you anticipate, what happens if you start to run out of space?  If you have a partition management software tool, you could expand the size of the allocation if there is more free space on the drive(s), or shrink another partition if that were possible and then increase the size of the desired one.  Or, if you have the space available, create another larger partition and move the data to the new one.

Using iSCSI targets is similar to this approach but without the drawbacks and pitfalls of locally attached drives.  First, your storage platform is robust and will have RAID enabled drive support.  Since mountable drives are created from an available pool of space, you can start with the most reasonable size for each disk you need.  Later, you can, on the fly, create a new iSCSI target that is larger or smaller, move or migrate the data to it, disconnect the original target and then delete it.  It is far easier than partition management.

Don’t forget backups.  You can create an iSCSI target and mount it on the SBS server and then configure backups to this drive.  Need another destination?  Very simple.  You get the idea.

Virtual Machines

You probably know from reading some of my other posts I am a fan of virtual machines.  I like the idea of running SBS as a Hyper-v machine; the same box can support test machines, client machines used for remote access, special LOB servers, you name it.  In a virtual machine environment, iSCSI shines.

Start with the drive on which you store the .vhd files.  These can be on a locally attached or a iSCSI drive.  I use iSCSI because I can allocate a right-sized disk in a matter of minutes and have it available on the host server.  Once the virtual machine is created, I can allocate and attach additional iSCSI targets to meet the needs of that vm.

Consider that you might want to test some new software or application, such as a web site, SharePoint feature, or LOB application.  Create a virtual machine and allocate the disk space it needs.  If it turns out to be incorrect, or once your testing has been completed, it is a simple matter to delete the iSCSI targets and return the disk space back to the available pool.

Note a potential disaster recovery scenario.  If you were to lose the host server, the .vhd for the virtual machines would still be on the iSCSI target.  Simply use them to create a virtual machine on another host, and you are back up and running.

Testing

Admittedly, I stole some of my own thunder when talking about virtual machines, but the testing environment is perfect for iSCSI.  Just allocate a target, use it and then delete it once the testing is done.

But it is not just for server and server-level software that iSCSI is useful in testing.  Suppose you want to test from your desktop.  Guess what.  Windows 7 has the same iSCSI initiator, and you can download one for XP.  That means you can create disks, use them and subsequently delete them at the client desktop as well as at the server.

Ad Hoc Uses

I have also used iSCSI targets for quick, one time efforts.  I wanted to update the OS on a laptop for a friend, and I wanted to end up with a clean install but make sure I didn’t lose anything important.  The trouble was that my friend couldn’t tell me what was important…. So I removed the laptop drive, connected it to my desktop with a USB drive connector, copied it completely to an iSCSI target I created, put the drive back in his laptop and installed the new OS.  There were a few things to go back and retrieve, but once he was satisfied I simply deleted the drive.

I will often be called upon to change something at an installation.  I usually create an iSCSI target, do an appropriate backup (sometimes it is just copying files, other times, a more holistic backup), then make the changes.  Getting back to the original state if something goes wrong is neat and tidy; so is the deletion of the disk once I am done.

Less Common But On My Wish List

Recall from Part I that the SCSI commands to read and write data are sent over the network to the target device.  Theoretically, it doesn’t matter whether the network is local or very WAN.  Practically, it is how long it takes for the commands and data to get back and forth.

Here is where I think cloud backups might go for some types of transaction-sensitive data.  Suppose you have a database that gets updates continuously from user transactions, web traffic, etc.  If that data were stored on an iSCSI target, remember that the data and commands to read and write it travel across the network.  Now imagine that the iSCSI target machine, when it gets a write command, also sends that command with the data to another iSCSI target, a mirror, that is remote, i.e., the cloud (public or private).  The difference is that the local target can respond back to the server that the write is complete, but there are no such time constraints on the write to the cloud. The iSCSI target would have to create a queue of writes and execute them in order as they complete asynchronously to the writes it completes locally.  This is not unlike playing a log file against a database.

Because only writes need be executed across the WAN, this is a very efficient operation and with broadband speeds continuing to increase, such a scheme because a very practical continuous backup procedure.

No solution like this is commercially available that I know of, and it would not be appropriate for every application.  Nevertheless, you heard it here first if it does come to pass.

I hope this gives you a flavor of the convenience and wide range of uses that iSCSI provides. In Part III I will discuss the costs and purchasing of a unit.

 


Happy Thanksgiving.  It is snowing, and temps have been in the teens for the last four or five days.  Predicted to turn into rain and get into the 40°s today, and everyone is overjoyed about – rain?  In Seattle?  No way.

Microsoft has announced that SBS 7 will end up as SBS 2011 and is due for release in December.  I have heard from a friend of a friend who knows someone who has a friend who heard it from a barista at Starbucks who is dating a guy who used to know someone who worked at a company that is located near Redmond that December 12 is the earliest.  Don’t take this to the bank.  Microsoft’s announcement also said that OEMs wouldn’t start shipping until around February.

Here are a few other items to note.

  1. Three flavors of SBS 2007
    • Basic – Code name Aurora in the beta test.  It is an on-premise server but integrated to Exchange and SharePoint 2010 in the cloud.
    • Standard – SBS 7 in beta test and what you got in SBS 2003/2008.  On premise server and Exchange and SharePoint running on that server.
    • Premium – A second Windows 2008 R2 license.
  2. Changes from SBS 2008
    • Windows 2008 R2 as the base level OS (instead of Windows 2008)
    • Exchange 2010 instead of Exchange 2007
    • SharePoint Foundation 2010 instead of SharePoint Services 3.0
    • Basic version with cloud integration
  3. Upgrading
    • No in-place upgrade.  Migration (both old and new systems running for a while) is the only option, if you currently have SBS 2003/2008.
    • You will need a 2nd server for the migration, but it doesn’t have to be a permanent home for the new OS.

I have several opinions about what to do if you upgrade that will not only make the migration a bit easier, but in fact will give you a more powerful and flexible infrastructure afterward.

  • Establish your new, target server as a virtual machine OS.  I am definitely a fan of Microsoft’s Hyper-v technology as it is free, works well, and is pretty straightforward to use.
  • If you have a license for Windows 2008 R2 or Windows 2008 (standard or above in either case), you can install that as your base OS for the hyper-v machine.  (If you have the Premium version of SBS, then you have a license for it, provided you migrate from a server where it is already installed, if that is the case).
  • If you don’t have a license, then you can use the free version of Hyper-v Server from Microsoft.  Note that there is no GUI for this version and you will have to access most tools from a Windows 7 or 2002/R2 client by installing remote management tools.  It is somewhat straight forward, but there are a few details involving firewalls on each side, etc.
  • You can convert your existing SBS 2003/2008 server to a virtual machine once you have created a Hyper-v enabled server, but I would do that ONLY if you want to free up the server hardware it is running to use in your new SBS 2011 installation.  Otherwise, leave it where it is.
  • Install SBS 2011 as a virtual machine.  Perform the migration.

I am a fan of this because having a virtual stack of machines around is handy, very handy. If you need to test something, just create a virtual machine in a matter of minutes.  I have a handful of different virtual machines already created with different OS and configurations, and I can create a new machine from one of these right away.  I simply copy the .vhd file for whatever configuration I need to a new area or with a new name, start that machine and it’s ready to go.  When the testing is done, I simply delete the .vhd file and delete the machine from Hyper-v manager.

I am going to devote a few postings in the upcoming weeks on setting up a hyper-v stack and how to use and manage it.  Come back and check it out.

Let me end with a strong suggestion:  SBS 2011 is a rock solid product, and the new features of SharePoint Foundation alone make it worth the upgrade cost and effort. If you are still running SBS 2003, what could you possibly be waiting for?  I see lots of environments where the hardware is iffy at best, there are always issues with Exchange, and SharePoint Services 2.0 is essentially ignored.  Look, your business depends on this stuff.

Would you keep a piece of machinery around without doing anything to it for 7 or 8 years?  And unlike machinery, getting new stuff is not only much faster, better and easier to use, but costs only a fraction of what it did when you8o first bought it.  That is an investment you should easily make.

Happy Thanksgiving