Unable to browse My Network in a 2008 Domain

As Windows Server 2008 takes it’s place in more data centers, serving as a domain controller, design changes are starting to impact end users. One of these notable changes effects a workflow most users have picked up: browsing the network to find file servers and shares. We have seen more and more customers call in with an error similar to below (wording may differ from client to client): Group Policy, user and group permissions, as well as network addressing all check out.  What could it be? The above ability is called NetBIOS browsing, and is granted via a service called Computer Browser.  The Computer Browser service keeps track of all the computers, services (WINS, DHCP, Server, etc), names, and IP addresses on the local subnet.  In a domain environment, the domain controller (DC) with the PDC emulator role acts as the Master Browser.  The server with the Master Browser role keeps a copy of all the NetBIOS lists from the other subnets (if there are any), and publishes this list for clients and servers alike.  These lists are updated every 12 minutes. The ability diminishes in an environment where Windows Server 2000 and 2003 DCs are upgraded to Server 2008.  These symptoms will begin with remote sites disappearing from the Network list, or updates not being reflected for the local subnet.  They can also be more severe as in the case above where the ability is lost all together, and replaced with a fairly cryptic error not at all actually suggesting what the problem may be. This behavior occurs because in Windows Server 2008 the Computer Browser service is...

SharePoint Search problems on Server 2008?

After installing WSS3 SP2 on a clean install of Server 2008 x86 SP2 STD, and using SQL 2008 SP1 as the backend, I could not get any search results.  The setup is about as simple of a farm installation you can get, it is for a small number of users, and demonstration purposes, so everything is installed on a single machine virtualized on an HP server running VMware ESXi 3.5.  There are two site collections using different application pools, one enabled for anonymous access, and the other not. The search service is common to both, but the crawl account (data access) is unique. I kept seeing the following error, even ID 2436 in the Application event logs on the server: The start address <sts3://sharepoint.site.url/contentdbid={95260a4e-85ec-4fc9-8da6-27882bf9d8f3}> cannot be crawled. Context: Application ‘Search index file on the search server’, Catalog ‘Search’ Details:Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (0x80041205) Very frustrating.  Double and triple checked that the application pool identity was not running under a system account, and that the service was also not running under a system account, verified the crawl account had been added to all the correct sites and spaces with FULL READ access, check, check, and check. So I turned up Object Auditing under the local security policy on the server, and also turned up both trace and event monitoring.  After two days of troubleshooting,...

SharePoint SP2 Bug

!IMPORTANT! All installations of Microsoft Office Server 2007 that have installed SP2 for SharePoint Services are affected by the following bulletin.  In short, it has reset your license key putting the product in trial mode, and it will expire in 180 days without notice.  See the below article for the resolution, and more details....

WSUS 3.0 SP1 Computers with no status

The setup: Server 2003 R2 SP2, DC & DNS Roles, WSUS SP1 Fresh install, default website (80). The issue: No status  reported by clients (Servers and workstations), Event ID 13042 in the Application logs on the WSUS server Self-update is not working. After researching, I came across these 2 forums: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?pg=2&p=1&tid=853e8bb5-71c7-4bee-9392-d75dbbf21c6b&dg=microsoft.public.windowsupdate http://blogs.msdn.com/jjameson/archive/2008/04/08/wsus-clients-failing-with-error-0x80244019-after-installing-wsus-sp1.aspx The articles were close, but both addressed installing SP1 POST a typical WSUS 3 install, mine was a fresh install at the customer’s site.  The SelfUpdate.msi file was missing, but there was a VB script: installselfupdateonport80.vbs I followed the procedure noted in the forums, and created a SelfUpdate virtual directory as the path did exist, and the files and folders specified were present, including the 2 CAB files.  I set the permissions accordingly, adding the IUSR_ServerName account, as it was missing from the NTFS entries on the SelfUpdate folder located at: %ProgramFiles%Update ServicesSelfUpdate Additionally, I ensured that anonymous access was enabled on the newly created virtual directory within IIS. I then ran iisreset /noforce from the command line on the WSUS server, and then executed the VB script mentioned earlier. After roughly 10 minutes, the clients began updating their status, and I received the Event ID 13040 Self-update is working. Next, I ran wuauclt.exe /detectnow on a client machine, waited a few minutes, and checked the update logs at: %WINDIR%WindowsUpdate.log And verified it was successfully communicating with the WSUS services, it was.  WSUS status issue resolved. At the time of this post, MS has not released any hotfixes, or updates to the installation, and this seems to be a pretty common issue.  Hope it...