Troubleshooting WDS: Event ID 257 – 258 – 266 – 513
January 14, 2009 at 12:58 pm | Posted in Windows Deployment Services (WDS) | 12 CommentsTags: Troubleshooting, Windows Deployment Services (WDS)
Windows Deployment Services depends and works directly with Active Directory and DHCP, meaning that if any of those two servers are significantly modified, then probably you will not be able to start the WDS service and get the events ID:
Event Viewer from WDS Server

Event 257: An error occurred trying to start the Windows Deployment Services server.
Event 258: An error occurred trying to start the Windows Deployment Services image server.
Event 266: An error occurred while to refreshing settings.
Event 513: An error occurred trying to initialize provider WDSImgSrv from C:\Windows\system32\WdsImgSrv.dll. Windows Deployment Services server will be shutdown.
Disclaimer
Please note that the following possible reasons, are related when all those events appear simultaneously and with the same descriptions.
Event ID 513 can also appear regarding to a PXE provider error: “An error occurred while trying to initialize provider WDSPXE from C:\Windows\system32\wdspxe.dll. Windows Deployment Services server will be shutdown”. This particular error could happen for several reasons, like installing on the same server a System Center Configuration Manager PXE provider that replaces the WDS.
Possible Reasons
Those particular errors appeared when there were changes on Active Directory that did not were performed smoothly:
- Changing a Global Catalog from Domain Controller.
- Shutting down an active Domain Controller.
Solution
To solve this, you need to insert manually the FQDN of the domain controller working as a Global Catalog.
1 – Open the WDS snap-in and access server properties.
2 – Click on "Advanced". And you should see the following:

3 - Insert the FQDN of a Domain Controller and the Global Catalog nearest to WDS and currently active (preferred in same site). Most likely will be the same DC on both options.
4 – Start the WDS Server.

More Background about WDS and Active Directory Integration
The PXE provider delivered with Windows Deployment Services is called BINL (implemented in Binlsvc.dll) and has a direct integration with Active Directory services in many ways:
- BINL prefers to use domain controllers and global catalogs that are available within the same Active Directory site as the PXE server (local).
- A writeable domain controller for the domain where the Windows Deployment Services PXE server resides will be leveraged when querying for selected attributes.
- The WDS PXE provider uses the DSGetDcName() API. It passes the DS_GC_SERVER_REQUIRED flag whenever it needs to locate a global catalog.
- When attempting to locate computer account objects, the default search order is for BINL to search global catalogs before searching domain controllers.
- And of course, BINL connects directly with AD when trying to create Computer objects within the domain; or querying for other attributes.
Example of BINL handling PXE requests and integrating with AD

For more info, check "Deploying and Managing the Windows Deployment Services Update".
Hope it helps!
Cheers!
If want to learn about troubleshooting wds then go through the testking 642-873 tutorials and testking 70-291 study guide for complete information and become IT expert using testking 70-432 training products
Hyper-V Server: Installing, configuring and troubleshooting
December 12, 2008 at 7:42 pm | Posted in Hyper-V, Virtualization, Windows Server 2008 | 4 CommentsTags: Hyper-V, Hyper-V Server, Troubleshooting, Virtualization
It’s been a few weeks since its release but I finally managed to put my hands on to Hyper-V Server.
I was very curious about it: A free operating system released by Microsoft working only as an HyperVisor it makes wonder about a lot of things. Also recently I’ve been working with VMWare ESX Server 3i, that is also the hypervisor working directly on the machine, and I had a good experience (I really loved the monitoring and reporting features that you can use).
From the moment I started using Hyper-V Server few troubleshooting tasks needed to be done.
Installing Hyper-V Server
If you ever installed any operating system, ever, you should not have any problem with this. You’ll of course see that the process is identical from Vista and Windows 2008.
To get started with Hyper-V Server there’s available the Hyper-V Server 2008 Configuration Guide.
If you want to avoid almost any command line to be executed from now on, Hyper-V Server has a simple tool where you’ll load a menu to access most of the configurations you will need. You can access it using this cmd:
C:windowssystem32hvconfig.cmd
But I’ll execute the next steps using the command line features, so this procedure will apply as well for Windows 2008 Server Core.
Managing Remotely
To start using Hyper-V Server you will need Hyper-V Console on your Vista SP1 (remember: there’s no other option for an Hyper-V Server to be managed remotely), it is the same console to manage remotely any other Windows 2008 with Hyper-V. If you don’t have it yet, you can download it from here:
Windows Vista Service Pack 1 Management Tools update for the release version of Hyper-V
But, from this moment I started to have a few problems.
1. Solving “Access denied. Unable to establish communication between: <Hyper-V Server> and <Vista client>”
For all of those who were using the early versions of this remote console probably had the same error.
The solution is the same, so I want to reference this post from John Howard’s blog; where it explain almost everything you must know about configuring Hyper-V role on a Windows 2008 Core Server. Hyper-V Server works the same way as this Core version of Windows 2008, so every step of configuration will apply.
Here’s a quick summary of the steps involved, I’m only applying the steps I considered necessary for my environment.
1. Since I’m using a domain environment, I joined this machine to the domain using NETDOM utility:
netdom join <ComputerName> /domain:<DomainName> /userd:<UserName> /passwordd:*
/passwordd: * Requires user password to be entered.
Reboot the machine to apply the changes:
shutdown /t 0 /r
2. Adding necessary rules on the Firewall to allow remote connections.
a. Remote Management:
netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes
Note: You can also use netsh to change server’s IP, using the following syntax:
netsh interface ip set address “<Adapter Name>” static ipaddr subnetmask gateway metric.
b. Enable Remote Desktop
cscript windowssystem32scregedit.wsf /ar 0
cscript windowssystem32scregedit.wsf /cs 0
c. Reboot the machine to apply the changes:
shutdown /t 0 /r
3. Solving the “Access denied” error from the client:
Now that the server is properly configured for remote management, you have to run a simple procedure to fix this common error:
a. On “Run” insert “DCOMCNFG“. Click OK
b. Expand “Component Services“, expand “Computers“. Right click on “My Computer” and click on “Properties” (imagen)
c. Now click on “COM Security”
d. In “Access Permission” click “Edit Limits”
e. Select “ANONYMOUS LOGON” in “Group or User Name“. In the column “Allow“, set the “Permissions for User” with “Remote Access“.
Now you should be able to connect remotely using the Hyper-V console.
Since I finally completed the Hyper-V Server configurations for remote management, so the obvious next step is creating a new virtual machine.
I started with a dummy virtual machine, just for testing. But in the last step of the virtual machine creation wizard I got “The virtual machine could not be started because the hypervisor is not running.” Ouch!
2. Solving “The virtual machine could not be started because the hypervisor is not running”
You should not worry if you see this error. There’s a good chance that your hardware is not the problem and that the hypervisor feature on your processor it is running.
Even though that the hardware on your server supports Hyper-V and that the service is correctly installed, what happens is that the hypervisor was not added on the boot environment and the service was not started.
To solve this, you only need to run this command line:
BCDEdit /set hypervisorlaunchtype auto
Ok, NOW you can start using Hyper-V Server.
Adding Features to Hyper-V Server
Don’t get all excited, as we mentioned before, this is just an HyperVisor and you should not expect that much functionality available.
Most of the features (not roles) that you can install are there to increase security and to achieve interoperability with other platforms like System Center Virtual Machine Manager or Data Protection Manager, supporting Live Backup (backing up virtual machine without downtime) as well.
To access all features available, as in Server Core, from cmd:
oclist
To install one of the features use: start /w ocsetup <NameofService> (for instance, I installed on this Hyper-V Server the TelnetClient)
You’ll find as well that Hyper-V Server includes a WMI interface for remote management extensibility. Here you can find more information:
Hope you find it useful.
Cheers!
Common issue using Team Foundation Server with an external connection: Documents and Reports items becomes unavailable
December 12, 2008 at 4:35 pm | Posted in Team Foundation Sever | 2 CommentsTags: Source Control, Team Foundation Server, Troubleshooting
Team Foundation Server is a very useful tool for team work, badly designed (no secret about that), but useful. The definition itself for TFS almost obligates you that this tool must be accessible not only from the internal network from your company, but also must be from external networks and the Internet.
That’s when the problem appears. If you use Internet as the media to connect to TFS, probably you have this issue: even with all the permission in place, the Documents and Reports items from Team Explorer becomes unavailable.
Like you know, you can use the FQDN (fully qualified domain name) of the Team Foundation Server name as the connection’s name with Team Explorer, for example: server01.domain.com. Or even you can use the server’s IP. But what happens if you want to work at home with any project within TFS?. If you don’t have a VPN (virtual private network) at your organization to make valid connections with Active Directory it can be very difficult to accomplish that.
First you must achieve that you actually have a FQDN available to be used over the Internet. For example, if you own a web site for your organization, like http://www.mycompany.com, you can add a DNS record (tfs.mycompany.com) as a valid connection for your server. This post it’s intended to solve the named issue for TFS and not to guide you for a proper configuration of TFS over Internet, we can dedicate that topic to another post.
Let’s focus on the problem. You have everything in place for a TFS connection over the Internet but you get the Documents and Reports items unavailable, like if you don’t have the proper permissions in place. This is a common issue within the SQL Reporting Services and the FQDN of your TFS connection. Here’s the solution:
1 – Open cmd on your Team Foudantion Server. If you have a dual-server configuration, this must be done on the Application Tier.
2 – Type “cd %programfiles%Microsoft Visual Studio 2005 Team Foundation ServerTools” and press enter.
3 – Run “tfsadminutil activateat “
4 – Run “regedit.exe“.
5 – Access HKEY_LOCAL_MACHINESOFTWAREMicrosoftVisualStudio8.0TeamFoundationReportServer
6 – Right-click on the “Key” record and select “Modify“.
7 – Insert the TFS FQDN that you use over the Internet connection.
Now test again the connection with your Team Explorer and all the items should be available to you.
I hope you find it useful!
Cheers!
Troubleshooting DCDIAG error: RPC Server is unavailable
December 12, 2008 at 4:21 pm | Posted in Active Directory, DNS, Windows Server 2003 | 1 CommentTags: Active Directory, DCDIAG, DNS, Troubleshooting, Windows Server 2003
It’s a common best practice to run the DCDIAG tool in all DC in your forest whenever a significant change has been made, i.e. a new DC has been added or deleted in the forest. With this you are testing if the change you just made was done correctly.
It’s also common that if you have at least two domains in your forest (and the trust relationships in place), when you run dcdiag in any DC you get a message indicating that when the test of replication on a specific server applies, it fails indicating that the “RPC Server is unavailable”.
Well, if you see this message you probably check if that the RPC service is up and running on the server… running in cmd “net start rpcss”. But the command prompt answers you, “don’t worry dude, the service was already running”.
“Alright then…” you say, “Let’s try DCDIAG again”… and you get the same error like the first time…
And then you go like “Hmmmm… why do I keep getting the same “RPC Server is unavailable” error?”
And then I say “I know why dude!”… And then you “You do? Is there any way I can solve it?”…
“Of course, why I’ll be posting something that I don’t know the answer!”… and then…
OK, enough with the theatre…
This issue appears when the configurations between the different DNS servers are not compatible. It’s something like this: you have a correct configuration in a DNS server that forwards any requests that does not belong to his domain ; but in the second domain, the DNS server does not forward the requests that ask for the first domain… was it clear? Let’s do a picture then!
In this graphic, a contoso domain member it’s trying to get something from fabrikam, the DNS Server from contoso receive the request and see that it belongs to fabrikam and forwards the request to the correct DNS Server. But in the other side, a fabrikam user wants to get something from contoso but when it gets the requests, see that it’s not for fabrikam and it does not have anything that says that the request must be forward it to another DNS Server, so can’t solve the user’s request.
After naming “forward” several times you probably know where the problem is: The forwarders on your DNS servers are not set correctly. The most like problem is that having different domains in the same forest, the DNS servers from each domain don’t know were to direct the requests for all the other domains.
Let’s take one server to solve this problem: Access the DNS snap-in of your DNS Server, on “Properties” select the “Forwarders” option and select “New” in DNS Domain and add all the domains in your forest; and put the IP address to the DNS server holding that domain.
In this case, LEONARDO is DNS Server for CORPNET and I’m adding in the Forwarders configuration that any request for EXTRANET, my second domain in the forest, are been forwarded to its DNS Server. In EXTRANET the same configuration must be set, of course
Also there’s another way to solve this problem. You can add an EXTRANET zone in CORPNET Forward Lookup Zones that holds all of the DNS records for this domain. In this case you must also set, in EXTRANET DNS, the properties for this zone, to “Allow Zone Transfers”, letting another DNS server, CORPNET, to also have the records for this zone. But, in my opinion, is also a good idea to not over charge your DNS server with all kind of request, so if it’s not for his domain, forward to the correct DNS server for resolution.
If the error keeps appearing, then you should check the trust relationships between domains. And any other error message that DCDIAG shows in all DCs.
Cheers!
Troubleshooting a special case for domain controllers and DNS servers
December 12, 2008 at 12:58 pm | Posted in Active Directory, DNS, Windows Server 2003 | 1 CommentTags: Active Directory, DNS, Troubleshooting, Windows Server 2003
“My DC is online, the TCP/IP it´s OK, the DNS service running but I still cannot make a valid connection with AD! “
This is a problem that can be present in many ways. The most common example is: you have your DC completely configure for Active Directory, the DNS server too, and you try to join a workstation to your domain and the following error appears:
An Active Directory Domain Controller for the domain [yourdomain.com] could not be contacted.
Ensure that the domain name is typed correctly
(…)
First of all, the obvious: Check that the connectivity is working fine… the DNS server and the DC both of them responds to PING requests. It’s most likely that if you cannot connect to the domain, the PING requests for the FQDN (such as: ping dcname.yourdomain.com or ping yourdomain.com) will not respond as well… but with the IP parameter should be working… if it’s not, then there’s definitely a connectivity problem, a bad TCP/IP configuration or a firewall within the way .
Well, let’s see, this is a problem that can really make you nuts trying to solve it.
Let’s assume that you have the correct configuration in your DC and workstations. If you have a DHCP server in you network, check that he is doing his job… giving the correct IP address for the workstations, the subnet mask, the DNS server and the other parameters that you are using.
DCDIAG really? Can that help me?
One of the possible reasons of your problem is that DC didn’t register himself in the DNS for let the AD know that he is a valid domain controller. To do that, use the DCDIAG tool (included in the Windows 2003 Support Tools) as it follows:
dcdiag /test:registerindns /dnsdomain:yourdomain.com /v
Where yourdomain.com is the complete FQDN of your domain
If everything goes ok, you will get a message like this:
Using NSLOOKUP
NSLOOKUP is a very helpful utility to test the name resolution in a DNS server. You’ll use this tool to check the SRV (service) records are in place for the correct functionality of Active Directory.
Type in the command line nslookup and press enter. You will probably find a message like this:
“*** Can’t find name server for the address : Non-existent domain”, don’t worry about it. This happens when you don’t have set any PTR (or reverse records) in your DNS server, to resolve IP address in names.
Carry on then, at nslookup (”>”) prompt type:
set q=srv press enter.
Then type: _ldap._tcp.dc._msdcs.yourdomain.com
Again, sometimes because you don’t have any PTR records you may find some “time out” messages, but there is nothing vital at this point.
If there is no problem with that, you will see the DNS server name and its IP address… if you don’t, you still have one thing to do.
That thing you never wanted to do… modifying a .dns file
The file that probably will save you is saved in: C:WINDOWSsystem32config and with the name netlogon.dns.
You have to open this file with the notepad and take a look to it, but don’t get frightened! … You will see a bunch of lines that will probably don’t have much sense to you, but one of them we are looking for:
_ldap._tcp.yourdomain.com IN SRV 0 0 389 ldap_server_name
_ldap._tcp.dc._msdcs.yourdomain.com IN SRV 0 0 389 domain_controller_name
The LDAP server name should be the same for the DC server name. So if you are going to manually change this file, use them as the same.
I’m gonna publish some other documents for similar problems. They all are from situations like you lost your only DC and you get back on service an old backup that has a different configuration. Check them too.
Cheers everyone!
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.


Computer geek, totally fan of the latest's IT platform solutions. Since 2006 I've been mentioned as Microsoft Student Partner, I continue working with them, collaborating on different academic and technological events. On this blog, you'll find most of the experience I have evaluating, designing, implementing and managing those technologies.

