Tuesday, July 17, 2018

I suppose I should make an effort to blog at LEAST once a week.  I'll try to.  I don't really have any subscribers, but I do still have many things to share with all.  I'll continue to make an effort to post on any IT challenges that I have come across regardless of any past content.

Thank you!

Wednesday, October 28, 2015

How to correct User Profile Disk and temporary profiles in 2012 R2 RDS


How to correct User Profile Disk and temporary profiles in 2012 R2 RDS


I ran across this thread last night after revisiting the issues I was having with RDS, User Profile Disk connections, and Intermittent temporary profiles.
I had already processed all of the Profile list Registry entries, deleted countless profile disks, looked for any fixes anywhere, and pounded my head until I wished I had passed out already.  This thread became my saving grace... so to speak.
I have the typical setup: GW -> CB -> Session Host Collection.
All of my external users use the GW, and internal users use old school 2008 R2 Round Robin DNS.  This method works, but will kill  you in the long run.  Temporary profiles on your down level RDP clients (thin clients) will cause you nothing but grief with your User Profile Disks.  Plus 2012 R2 RDS uses the Connection Broker services to point you to the right server.  The round robin approach is dated. 
2012R2 RDS works best by sending everything through the connection broker service on the CB server.  This will allow the CB to determine the Session Host (we're just talking session hosts here and not VDI) that you will connect to.  
***If you are using RR DNS then you need to get rid of the RR registry entries, and create an A record that just points to the Connection Broker server.***
We will then need to edit the registry on the Connection Broker to redirect all inbound clients to your session host collection.
In order to edit the CB registry we need to find out what to enter.  Connect to RDWeb via Chrome, enter user / pass and right click and save the Session Host connection icon. 

If you don't see it you will have to edit your remote desktop collection properties, and check off to "Show the session collection in RD Web Access" 











Right click on the .RDP file that you just saved, and edit it with notepad.
Find the line: “loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.NAME OF COLLECTION”
In my case it was this exact line including the truncated name:
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Remote_Desktop_S
Now you need to take that line and create a Registry Entry on the Connection Broker.  
Login to Connection Broker server and open regedit. Browse to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings
Create new stringValue: DefaultTsvUrlThen paste earlier copied path to Value data: tsv://MS Terminal Services Plugin.1.NAME OF COLLECTION"
This is how mine looked when I entered it:




Remember if you need to connect directly to your connection broker server VIA RDP use the 'MSTSC /admin option, or download remote desktop connection manager from MS, edit the properties of the connection to your CB and select the 'connect to console' option.
Remember a few things though.  If you are using older thin clients you will probably receive authentication errors.  The link that I posted above states:
"Please note that if the thin clients do not properly support at least RDP 8.0 then the users may get a poor experience.  I have seen in the past where people complain about 2012 R2 RDSH and it was because the thin clients they were using only supported up to RDP 6.x/7.x or similar.  Some devices don't even fullysupport the lower version."
I have already experienced this issue stated above.  I have not found a fix for it other than swapping out new TC's. Hopefully I can find some firmware or some other solution quickly before I just completely ditch UPDs.

Thanks!

Monday, February 24, 2014

Exchange 2010 Distribution Groups INSUFF_ACCESS_RIGHTS

I recently performed an Exchange 2003 to 2010 migration.   Everything seemed to go ok, but there were a few glitches here and there, including this one.  I got a call from a user who manages certain distribution lists from within outlook.  She could no longer add/remove users from the groups.  This wasn't a problem prior to the migration.

I jumped on EMC and tried to check the permissions of the DL and it spit a nice error out at me:

Error:
Active Directory operation failed on SERVER.DOMAIN.COM. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
The user has insufficient access rights.
Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.267.0&t=exchgf1&e=ms.exch.err.Ex6AE46B

Exchange Management Shell command attempted:
new-DistributionGroup -Name 'Test Group' -SamAccountName 'Test Group' -Alias 'NJTest'

Elapsed Time: 00:00:00

Of course, it can be weeks after the migration before stuff like this pops up, so I had to go digging around for an answer.  I found a few things on technet, but nothing stood out.  I changed and checked the following to try to fix the issue:

  • Changed all of the DL's to Universal groups
  • Changed all of the Distribution groups to 2010 DL's 
    • I did this by renaming the DL from within EMC, clicking apply, and reverting the change
  • Ensured that I had permissions on the object from ADUC
I was able to check the permissions and change all of the DL's to 2010 DL's, but when I tried to change the problem DL's (rename and revert), I was greeted with the same error.

I then checked the differences between the DL's that worked and the DL's that were not allowing admin's / owners to change their DL's from within Outlook.  I noticed that the inherit permissions wasn't checked on the two DL's that were not working.  I checked it and it immediately started working.  I was able to change the DL's to 2010 DL's and I checked with the users and they were able to add and remove users from within Outlook.

Hope this helps

Tuesday, February 18, 2014

How to remotely enable/disable the firewall in Windows 7 / 2008 R2, and change RDP listening port

Had an issue about a month ago. I had to change the listening port on a user computer that had been changed from default RDP 3389 to 67890, but I couldn't get to it with COMPUTER:67890 (inside or outside the network).  Everything WAS setup with a group policy but for some reason, when it was removed, the settings stayed on the computer.  Regardless, the computer was still listening on 67890.  So, I decided to remotely change it back to 3389, and ensure that the service worked afterwards without rebooting the system.

Again, this is a remote operation so I needed tools.  My First step: download PSTools if you don't already have it.  It includes one of the best system admin tools known.... PSEXEC.   This program will allow an admin with full domain privileges to all domain computers run remote commands on that computer.  Get PSEXEC and the rest of PSTools from here: Here 

Be sure to double click on PSEXEC after you have extracted it.  This way you won't get the disclaimer when running PSEXEC commands.  Also, I find it helpful to just extract the PSTools to a directory that is already a system path (C:\Windows, or C:\Windows\System32).




Second, I had to open up a administrator command prompt on the target machine.  I did this by opening an admin command prompt and then ran psexec \\COMPUTERNAME cmd.exe.  This command allowed me to connect to the target via cmd prompt, and physically run commands on the target computer.


I used this to disable the firewall on the target workstation, by typing in the following commands on the target cmd prompt: netsh advfirewall set allprofiles state off.  


This command will turn off the Domain, Public, and Private profiles on the target computer.  If you already have them disabled via GPO or something local, then skip this.  Otherwise you may want to re-enable it prior to completion: netsh advfirewall set allprofiles state on.

Third, I had to start the remote registry service on the target machine.  Opened up services on my machine, and remotely connected to the services on the target machine.  I right clicked on Remote Registry Service and started it.




I then attached to the registry on the target machine by opening up regedit, clicking on File, Connect, Network Registry, and typing in the target computer name.





Lastly, the RDP port had to be reset to default 3389.  I had to dig into the registry on the target machine to change it from 67890 to 3389.  I searched MS and found the following from: http://support.microsoft.com/kb/306759
  1. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
  2. On the Edit menu, click Modify, and then click Decimal.
  3. Type the new port number, and then click OK.  (TYPE 3389)
  4. Quit Registry Editor.
  5. Restart the computer.


Granted, it does say restart the computer, but I was able to RDP into the target computer from my workstation right after changing this.  Also, I am using NLS, so this wasn't the reason.

Thanks!


EDIT:

Thanks to JH, a powershell script he created accomplishes this much better and faster.  Please use this in combination with the above is stuck:


 #Enable remote desktop on computer in computer OU

 

$creds = Get-Credential

 

$PCName = read-host " Enter Computer Name"

 

Enter-PSSession -ComputerName $PCName -Credential $creds

 

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server'-name "fDenyTSConnections" -Value 0

 

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"  

 

 


Monday, December 2, 2013

How to setup 2008 R2 Password Expiration Notification

Had an issue with my remote desktop services / Terminal Services users not changing their passwords because Microsoft has so awesomely changed the way a user gets notified

From this:


To this:

Now I don't know about you, but I find this revolting.  I know that an administrator, and savvy users would eventually pick up on the notification in the corner, but why change a good thing?

Anyways, with some googling I have come up with a way to get all of this together with GPP.

Pretty simple really once you get the script going.  All we need to do is make sure that the newly created GPO with the preferences is linked to the OU where the Terminal servers are.



       
'==========================================
' Check for password expiring notification
'==========================================
' First, get the domain policy.
'==========================================
Dim oDomain
Dim oUser
Dim maxPwdAge
Dim numDays
Dim warningDays
warningDays = 14
   
Set LoginInfo = CreateObject("ADSystemInfo")  
Set objUser = GetObject("LDAP://" & LoginInfo.UserName & "")  
strDomainDN = UCase(LoginInfo.DomainDNSName) 
strUserDN = LoginInfo.UserName
'========================================
' Check if password is non-expiring.
'========================================
Const ADS_UF_DONT_EXPIRE_PASSWD = &h10000
intUserAccountControl = objUser.Get("userAccountControl")
If intUserAccountControl And ADS_UF_DONT_EXPIRE_PASSWD Then
'WScript.Echo "The password does not expire."
Else

Set oDomain = GetObject("LDAP://" & strDomainDN)
Set maxPwdAge = oDomain.Get("maxPwdAge")
'========================================
' Calculate the number of days that are
' held in this value.
'========================================
numDays = CCur((maxPwdAge.HighPart * 2 ^ 32) + _
maxPwdAge.LowPart) / CCur(-864000000000)
'WScript.Echo "Maximum Password Age: " & numDays

'========================================
' Determine the last time that the user
' changed his or her password.
'========================================
Set oUser = GetObject("LDAP://" & strUserDN)
'========================================
' Add the number of days to the last time
' the password was set.
'========================================
whenPasswordExpires = DateAdd("d", numDays, oUser.PasswordLastChanged)
fromDate = Date
daysLeft = DateDiff("d",fromDate,whenPasswordExpires)

'WScript.Echo "Password Last Changed: " & oUser.PasswordLastChanged
if (daysLeft < warningDays) and (daysLeft > -1) then
Msgbox "Your password will expire in " & daysLeft & " day(s)" & " at " & whenPasswordExpires & chr(13) & chr(13) & "Press CTRL + ALT + END and select the 'Change a password' option." , 0, "Password Expiration Warning"
End if
End if
'========================================
' Clean up.
'========================================
Set oUser = Nothing
Set maxPwdAge = Nothing
Set oDomain = Nothing

Now just create a GPP, link it to the OU where the Terminal Servers are located and edit the registry like so in the GPP:





The GPO when completed:


















Now, notice that this GPO is a user level configuration GPO, but that is the beauty of this GPP.  It runs under the registry setting of HKCU.  The server is automatically going to process this script no matter who is logging in.  I just have to link it to any GPO that I want users that are logging on to be notified that their password is about to expire.  Now after gpupdate, I login to my Windows 2008 R2 terminal server and voila:











This message will compliment the notification area password expiration popup, but at least it is something that the users can see.

Enjoy.