One of our techs recently ran across a problem with a new Windows Vista Business laptop trying to synchronize offline files to a Windows Server 2000 file server. Synchronization would start, but the Sync Center in Vista would show failures for every single file that was attempted to be sync’d. The error message read something to the extent of “The process cannot access the file because it is being used by another process“.
We tried the usual: checking permissions on the folders being offline’d (I know that’s probably not a word, but you get what I mean); deleting his local cache of Offline Files; disabling and then re-enabling Offline Files. But we just kept on banging our heads against the same error. At first, just about any web search for the error resulted in either something about Windows Home Server or databases or something of the like. Eventually, though, we struck gold:
http://support.microsoft.com/kb/296264/en-us: Configuring opportunistic locking in Windows
Part I demonstrated how to find aged or inactive accounts, and in Part II we will look at another lingering account type: disabled accounts.
Like inactive accounts, Directory Searchers also come in handy for disabled accounts. We can also, however, read an Active Directory account’s status directly from a hidden attribute on the ADSI object. Let’s start with the Directory Searcher method. This entry also draws from Bahram’s Blog. The code:
$adobjroot = [adsi]''
$objdisabsearcher = New-Object System.DirectoryServices.DirectorySearcher($adobjroot)
$objdisabsearcher.filter = "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1135184.108.40.2063:=2))"
$resultdisabaccn = $objdisabsearcher.findall() | sort path
We’ll start off with Inactive accounts first, and then work on the disabled accounts after that.
Active Directory in Server 2003 has a nice user/computer attribute called lastLogonTimeStamp that can help us keep track of inactive accounts. If you have ever tried to use that attribute, however, you might have come up with something like this…
I am pretty sure I’m not the only one who wants something more descriptive than DSC1900298.JPG to name my digital photos. And yes, I know that Windows Explorer allows you to rename pictures en masse, but I don’t like the convention they have chosen in that the first file is named [common name].JPG, then the subsequent files are named [common name] (2).JPG and so on and so forth.
I had a few requirements for how I wanted to go about this:
- Get rid of the parentheses. If I will be posting those pics online anywhere, I wanted to keep the names as free of special characters as I can.
- Number the first file. The Windows Explorer route does not number the first file when doing bulk renames. This is easy enough to do manually, but I just don’t want to bother.
- Keep a constant number of digits in the index number. I want the renaming process to take into account how many pictures there are and adjust the number of index digits accordingly. If there are fewer than 10 files/images, then only 1 digit is required (e.g. 1, 2, 3, 4…9). If there are between 10 and 99 files (inclusive), then two digits are required (01, 02, 03…10, 11, 12…99). I think you get the idea. Windows definitely doesn’t do that.
As part of our process to disable user accounts, we take ownership of the user’s server-stored documents such as roaming profiles and redirected My Documents directories. We then either keep access restricted to the domain admins group or grant access to a replacement user who should receive access to the departed user’s files.
With an upgrade to Exchange 2007, we have taken advantage of the Powershell access to Exchange objects, and have scripted the mailbox provisioning and account disable processes. One of the sticking points in getting the disable script wrapped up was seizing control of the user’s directories. Now, Powershell does have the ability to modify ACL’s through the New-Acl and Set-Acl cmdlets (links below), but the users have exclusive access to their server-side directories. It is easy enough to take ownership of a directory through the Windows Explorer Security dialog, but the Powershell methods all presented some form of error when trying to set permissions or change ownership on a file system object to which you do not already have access to.
Dell, Broadcom, and Microsoft have decided to partner up with the release of a technology called TCP/IP Offloading, or TOE for TCP/IP Offload Engine. It was bundled together in the Scalable Network Pack (SNP), included and enabled by default with Service Pack 2 (SP2) for Windows Server 2003. The gist of this technology is to enable high-load enterprise applications to be easily scalable. For those of you familiar with the OSI model, TOE moves layer 3 and 4 processing out of the OS and CPU into the NIC. The idea is to better utilize advances in network card performance and free up CPU cycles for other purposes, such as application-side processing.
This all seems well and good, if they saw fit to properly test the stuff out against their own applications!