Daily IT Matters [DIM]

We’ve seen numerous reports of the following event within Microsoft and from our customers. EVENT LOG Application EVENT TYPE Warning SOURCE SRMSVC EVENT ID 12317 COMPUTERNAME SERVER2 TIME 5/1/2006 12:15:45 PM MESSAGE File Server Resource Manager failed to enumerate share paths or DFS paths. Mappings from local file paths to share and DFS paths may be incomplete or temporarily unavailable. FSRM will retry the operation at a later time. Error-specific details: Error: (0x80070005) Access is denied. Although this event doesn’t affect quota functionality, the fact that it occurs hourly has prompted numerous support calls from customers. We’ve isolated the cause and the solution for this event…well, most of the cause anyway. An Event 12317 showing access denied is caused when the NT AUTHORITY\Authenticated Users group is not a member of the BUILTIN\Users group in the domain. (As you might know, the local BUILTIN\Users group on a domain controller is mapped to the domain built-in group Users

Back up your important user data first. Purchase an external USB2 or IEEE 1394 (Firewire) hard drive and use it to back up important data from all your client systems. Afterward, you can use this drive for migrating data to the server and eventually it will become your backup drive for automatic server backups. Plan your network design. Take a look at the whitepaper "Understanding Your Network" on TechNet online (the link can be found in the "Additional Resources" sidebar) and choose the deployment scenario that best fits your home network design. Plan your external connectivity. If you want to set up your own Web site or receive external e-mail at your server, register a domain name. You might need to sign up with a DNS registration service like ZoneEdit or DynDNS if your Internet provider uses dynamic IP addressing. Plan your server. It doesn't take much to run a decent SBS server for a home environment. You'll need at least 512MB of RAM, two hard dr

Like most Windows products released in 2003, Exchange Server 2003 offers more manageability through Windows Management Instrumentation (WMI). As Table 1 ( http://www.winnetmag.com/microsoftexchangeoutlook , InstantDoc ID 40755) shows, Exchange 2000 Server was the first release in which Microsoft implemented WMI interfaces for Exchange. The original release offered three WMI providers: ExchangeRoutingTableProvider, ExchangeQueueProvider, and ExchangeClusterProvider. These providers are available from the Root\CIMV2\Applications\Exchange namespace. Later, Microsoft released Exchange 2000 Service Pack 2 (SP2), which introduced two new WMI providers in the Root\MicrosoftExchangeV2 namespace: ExchangeDsAccessProvider and ExchangeMessageTrackingProvider. Little difference exists between the five providers in Exchange 2000 SP2 and those same five providers in Exchange 2003. The only noticeable change is that Microsoft updated the ExchangeMessageTrackingProvider's Exchange_MessageTracking

Print Management (Printmanagement.msc) can be used with Group Policy to automatically add printer connections to a computer's Printers and Faxes folder. To do this, you use the Deploy with Group Policy dialog box to automatically add a printer connection setting to an existing Group Policy object (GPO) in Active Directory. When Group Policy processing runs on client computers, the printer connection settings are applied to the users or computers associated with the GPO. This is called deploying printer connections. Printers you deploy by using this method appear in the Deployed Printers object of Print Management tree when the print server they are connected to is being monitored. This method of installing a printer is useful in a laboratory, classroom, or branch office setting where every computer in the room or office needs access to the same printer. It is also useful in large organizations, where computers and printers are often separated by function, workgroup, or departmen

What Are Domain and Forest Trusts? Updated: March 28, 2003 In this section• Trust Scenarios • Technologies Related to Trusts Most organizations that have more than one domain have a legitimate need for users to access shared resources located in a different domain. Controlling this access requires that users in one domain can also be authenticated and authorized to use resources in another domain. To provide authentication and authorization capabilities between clients and servers in different domains, there must be a trust between the two domains. Trusts are the underlying technology by which secured Active Directory communications occur, and are an integral security component of the Windows Server 2003 network architecture. When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help provide for controlled access to shared resources in a resource domain (the trusting domain) by verifying

Lennart Wistrand here. This week we’ve seen both proof of concept code posted for a Windows Shell vulnerability. We have also seen limited exploits of a previously publicly disclosed vulnerability in DirectAnimation as well as limited exploits of a PowerPoint vulnerability. We’ve made the Windows Shell advisory available to advise customers of this public PoC. The advisory calls out mitigating factors and workarounds and does also touch upon our plans around releasing a security update that addresses this. The advisory can be found here. We’ve also made a small update to the DirectAnimation advisory to call out that we have seen very limited attacks occur. That advisory can be found here. Finally, we’ve published a PowerPoint advisory as well regarding limited attacks using specially crafted PowerPoint files. In each case, user interaction is required for a successful exploit to occur and our Safe Browsing guidance applies. Reading e-mail using Outlook or Outlook Express can, in an

Management and Security Considerations for Instant Messaging in the Workplace Microsoft Corporation Published: December 2005 Abstract This paper identifies potential threats to corporate computer security that can result from the use of instant messaging in the workplace. It discusses specific risks and defines steps that organizations can take to ensure the security of their collaborative work environment. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyr

The original article can be found here Bill: We are planning on building a root domain from scratch at our HQ called "root.com" and then having separate child domains for Europe and North America. Can you provide some "best practice" steps and information on configuring DNS prior to installing AD for an environment such as this? I'd be very appreciative. On a side note, our new 2003 AD structure will eventually include Exchange Server, but it will not start out that way. Will it cause any problems if we go ahead and extend the schema for the forest and domain ahead of time? If extending the schema will not be a problem, is it best to do it before or after the service packs are applied to the OS? —Steve Steve: It's a great idea to get your DNS infrastructure configured and tested prior to deploying Active Directory. Nearly all AD problems have a root cause in DNS. In your example, you specified a DNS domain name of Root.com. I'm assuming that you