Retrieving Citrix user accounts via PowerShell

Here's a neat little two liner to pull all the AD accounts associated with Citrix applications:

$accounts = Get-XAApplicationReport * | select-object Accounts

$accounts | foreach {$_.accounts | select-object AccountDisplayName} | export-csv "%userprofile%\desktop\app.csv" -noclobber

Awesome.

Query remote registry for My Documents location

A common question I get is, "Can we move all these users My Documents folder from Server A to Server B"?

"Sure," I'll respond, "we'll just update their AD home directory attribute and have them log off and log back on."

Inevitably, this will fail in some capacity.  The users don't wait for the copy to complete is an example and then it fails and the My Documents is still pointing to their old server.  To correct this issue you can pre-copy the files then when doing the login copy, folder redirection will only copy changed files.  This can still take a while but it's much faster then copying everything, especially with a big directory.

Eventually, I'll get asked, "we want to shut down the old server, can we verify that all the users my docs have been copied off and their computers are pointing to the correct location?"

In order to accomplish this effectively, I wrote a script that runs through a list of computers you give it and it checks the registry and presents you a list of all the network "My Documents" it finds.  This is the script:

:Find-redir.cmd

:This next bit will query the registry to see if they are redirecting already...
del /q "%temp%\redir.txt"


:you need to drop a list of computers on this file.


FOR /F "tokens=*" %%a IN ('type %1') DO (
  echo =============================================== >> "%temp%\redir.txt"
  echo %%a >> "%temp%\redir.txt"
  reg query \\%%a\HKU | findstr /V /C:"_Classes" | findstr /R /V /C:"S-1-5-1[89]" | findstr /R /V /C:"S-1-5-20" | findstr /v /c:".DEFAULT" | findstr /v /c:"!" | findstr  /c:"HKEY_USERS\S" > "%temp%\reg-user.txt"
  for /f "tokens=*" %%A IN ('type "%temp%\reg-user.txt"') DO reg query "\\%%a\%%A\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" | findstr \\\\ >> "%temp%\redir.txt"
  echo =============================================== >> "%temp%\redir.txt"
)
notepad "%temp%\redir.txt"





To use the script; get a list of computers or IP addresses and then run the script as:
find-redir.cmd "list-of-computers.txt"

The list of computers.txt can look like:
192.168.1.1
192.168.1.2
Laptop1
Laptop2

I've had a bit of a battle getting PowerShell to work on creating remote shares with the permissions I want. I think I have it working now in a fairly minimalist fashion.

    #create a share using WMI and PowerShell

    #

    #5/14/2012 - By Trentent Tye

    #

    #To create a share with PowerShell utilizing WMI (so you don't need

    #to use PSRemoting) you need to do the following:

    #1) Create the Win32_Share class

    #2) Create the Security Descriptor for the share

    #3) Create the ACE for the share

    #4) Create the Trustee fo rthe ACE

    #5) Set all the variables

    #6) Create the share.

    #

    #The next lines sets a computer (%cn%) to "EVERYONE FULL CONTROL" on the

    #share "HomeDirs"

    $cshare = [WMIClass]"\\%cn%\root\cimv2:Win32_Share"

    $securityDescriptor = ([WMIClass] "\\%cn%\root\cimv2:Win32_SecurityDescriptor").CreateInstance()

    $ACE = ([WMIClass] "\\%cn%\root\cimv2:Win32_ACE").CreateInstance()

    $Trustee = ([WMIClass] "\\%cn%\root\cimv2:Win32_Trustee").CreateInstance()

    $Trustee.Name = "EVERYONE"

    $Trustee.Domain = $Null

    $Trustee.SID = @(1, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0)

    $ace.AccessMask = 2032127

    $ace.AceFlags = 3

    $ace.AceType = 0

    $ACE.Trustee = $Trustee

    $securityDescriptor.DACL += $ACE.psObject.baseobject

    #trying to create share...  variables are:

    #,,,(if $Null set to maximum allowed),,,

    $result = $cshare.create("%homeDrive%:\homedirs","homedirs",0,$Null,"Home Directory Share",$Null,$securityDescriptor)

   

}

Enjoy!

Domain Controller doesn't replicate DNS and has other replication issues

We recently demoted a global catalog domain controller and then re-promoted because of issues we were having post-demotion. When a DC is demoted it changes it's computer account to have less rights then it would if it were a DC. Somewhere along the line the promotion didn't change it's account back and after the computer account password expired we started having replications issues. This didn't really affect us too much until 14 days after the password expired and the DC couldn't replicate back to the domain. All of our DNS zones couldn't replicate to it and subsequently became "stale" and were scavenged and removed. This caused issues for everyone at that site as they couldn't access various resources that we utilize DNS for.

The symptoms were:
All DNS zones were gone except for the primary zone.
"error no trust sam account" occurred while running "nltest /dsregdns"
This error was in the DNS event log:

"The DNS server detected that it is not enlisted in the replication scope of the directory partition ForestDnsZones.ccs.corp. This prevents the zones that should be replicated to all DNS servers in the ccs.corp forest from replicating to this DNS server.

To create or repair the forest-wide DNS directory partition, open the the DNS console. Right-click the applicable DNS server, and then click 'Create Default Application Directory Partitions'. Follow the instructions to create the default DNS application directory partitions. For more information, see 'To create the default DNS application directory partitions' in Help and Support. "

And this error:

The attempt to establish a replication link for the following writable directory partition failed.

dcdiag reported the last replication was 2 weeks ago
repadmin /showreps reported it failed.

The solution was from here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;329860

WARNING: If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Exchange 2000 Server, or both. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.
On a domain controller that is in the "healthy" part of the domain (not the domain controller with which you experience the issue), install the Windows 2000 Support Tools if they have not already been installed. For additional information about how to install the Windows 2000 Support Tools, click the article number below to view the article in the Microsoft Knowledge Base:
301423 How to Install the Windows 2000 Support Tools to a Windows 2000 Server-Based Computer
Start the ADSI Edit snap-in. To do so, click Start, point to Programs, point to Windows 2000 Support Tools, point to Tools, and then click ADSI Edit.
Expand Domain NC [server.example.com] (where server is the name of the domain controller and example.com is the name of the domain.
Expand DC=example,DC=com.
Expand OU=Domain Controllers, right-click CN=ServerName (where ServerName is the domain controller with which you experience the issues that are described in the "Symptoms" section of this article), and then click Properties.
Click the Attributes tab (if it is not already selected).
In the Select which properties to view list, click Both, and then click userAccountControl in the Select a property to view list.
If the Value(s) box does not contain 532480, type 532480 in the Edit Attribute box, and then click Set.
Click Apply, click OK, and then quit the ADSI Edit snap-in

List of exportable AD attributes

It appears the following AD attributes are exportable from LDIFDE or CSVDE:

DN,objectClass,ou,distinguishedName,name,description,sAMAccountName,objectCategory,instanceType,whenCreated,whenChanged,uSNCreated,uSNChanged,dSCorePropagationData,cn,member,groupType,displayName,info,extensionAttribute1,managedBy,publicDelegatesBL,extensionAttribute14,extensionAttribute15,mail,sn,givenName,homeMTA,proxyAddresses,homeMDB,garbageCollPeriod,mDBUseDefaults,mailNickname,protocolSettings,internetEncoding,userAccountControl,badPwdCount,codePage,countryCode,badPasswordTime,lastLogoff,lastLogon,pwdLastSet,primaryGroupID,accountExpires,logonCount,showInAddressBook,legacyExchangeDN,userPrincipalName,textEncodedORAddress,msExchHomeServerName,msExchMailboxSecurityDescriptor,msExchUserAccountControl,msExchMailboxGuid,msExchPoliciesIncluded,msExchMailboxAuditLogAgeLimit,msExchRecipientDisplayType,msExchAddressBookFlags,msExchRBACPolicyLink,msExchDumpsterQuota,msExchArchiveQuota,msExchRecipientTypeDetails,msExchMDBRulesQuota,msExchTransportRecipientSettingsFlags,msExchArchiveWarnQuota,msExchDumpsterWarningQuota,msExchUMEnabledFlags2,msExchModerationFlags,msExchProvisioningFlags,msExchUMDtmfMap,msExchBypassAudit,msExchMailboxAuditEnable,msExchWhenMailboxCreated,msExchTextMessagingState,reportToOriginator,msExchRequireAuthToSendTo,msExchALObjectVersion,msExchArbitrationMailbox,msExchCoManagedByLink,msExchHideFromAddressLists,msExchGroupDepartRestriction,msExchGroupJoinRestriction,reportToOwner,replicatedObjectVersion,replicationSignature,msExchADCGlobalNames,dLMemDefault,oOFReplyToOriginator,msExchPoliciesExcluded,delivContLength,authOrig,dLMemSubmitPerms,dLMemSubmitPermsBL,displayNamePrintable,altRecipientBL,adminCount,hideDLMembership,managedObjects

I've exported using CSVDE using all these attributes and managed to import back into a different AD domain (and finding and replacing DC=XXX,DC=COM) and these attributes appear to import cleanly without error