Citrix Receiver Progress Bar / Application open in background

In the newer versions of Citrix Receiver the connection progress bar / status bar launch in the background by default.  In addition once the application opens it is launched in the background.

Application opens in background:
There is a seamless flag that can be set that allows the application to open again in the foreground.  This is set at the XenApp server level.
HKLM\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI
dword=SeamlessFlags
value = 0x4

You can also set this at the Receiver client level.
http://support.citrix.com/article/CTX131977
HKLM\Software\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\WFClient
HKLM\Software\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\WFClient
Reg_SZ = TWISeamlessFlag
Value = 1


Progress Bar launches in background:
With Citrix Receiver 4.1 there is now a registry key that can be added to force the progress bar to the foreground.  This is set on the client.
http://support.citrix.com/article/CTX138197
HKLM\Software\Citrix\ICA Client
HKLM\Software\Wow6432Node\Citrix\ICA Client
dword = ForegroundProgressBar
Value = 1

CAS Array Object / RpcClientAccessServer

About a year and a half ago (somehow I forgot to post this) I needed to decommision an old Exchange 2010 server and move all the mailboxes to a new one due to a Hypervisor switch.  I learned a very good lesson then that I wish I'd known when I originally setup my first CAS server...

I quickly found that even though all the mailboxes where moved and all clients had connected to the new box that turnning off the old Exchange server caused Outlook to lose connection.  After looking for a few brief moments I found that they where still connecting through the old CAS box. ACK

http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx

I always thought of the CAS Array by what it's name sort of indicates, more than one CAS, but I was wrong and I paid for it.

You want to setup the cas array object to populate outlook with an FQDN that isn't server specific.  For instance outlook.domain.com.  You would then have DNS setup to tell Outlook which server to point Outlook.domain.com (or which load balancer).  Thus if you migrate to a new server you just update DNS.

Failure to do this results in having to touch each and every outlook install or using a prf to update (or some other method).

Do yourself a favor, setup a CAS array from the begining or if you already missed this step go ahead and setup the cas array and then begin slowly changing all your outlook installs to point to the array.


also read
http://blogs.technet.com/b/exchange/archive/2012/03/28/demystifying-the-cas-array-object-part-2.aspx

NETLogon not replicating - Replication service stopped replication on volume C

After a dirty shutdown of a Windows Server 2012 DC I found that my NETLogon was no longer replicating

Event log had event ID 2213 listed under DFS Replication:

The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Additional Information:
Volume: C:
GUID: guidofvolume

Recovery Steps
1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUIDofvolume" call ResumeReplication

In Server 2012 the default behavior has changed to a manual recovery from dirty shutdown.

http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr-dirty-unexpected-shutdown-recovery.aspx


In my case just executing the wmic command resolved.
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUIDofvolume" call ResumeReplication


At that point you can either start monitoring your eventvwr on your DC :)  or set this back to autorecovery
wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE

DHCP options for SIP server and SIP port

In a recent deployment of a VOIP system (NEC sv8100) I wanted to setup DHCP to hand out the SIP options.

This is pretty simple although some of the references I looked at made it look confusing.
For the system I was working on only two options are necessary, SIP Server IP address and SIP server port (if different than the default).

1. Open up DHCP, right click IPv4 and choose "Set Predefined Options"
2. Note that "option name" for 120 doesn't exist (unless added previously).  Click "Add"
3. Put in a name of SIP Server IP Address, Data type should be binary, code equals 120, and a description as you see fit.
4. Click OK
5. Go to your server options (or scope options depending on what you want). 
6. Click "Configure options"
7. Check mark option 043 Vendor Specific Info
1. This option specifies the port to use
2. enter the HEX value under the binary section with A8 02 appended to the front. For instance for port 5080 it would look like A8 02 13 D8
1. A8 = 168 sub option
2. 02 = required first byte
3. 13 D8 = 5080 in HEX
4. if you wanted port 5060 it would be A8 02  13 C4
8. Check mark option 120 SIP Server IP Address
1. Here you enter the SIP server IP address in HEX format with a 01 appended to the front.
2. Then the ip, so 192.168.1.2 would be C0 A8 01 02.
3. Put the 01 in front and get 01 C0 A8 01 02
4. 01 = indicates that it's the first sip server
5. C0 = 192
6. A8 = 168
7. 01 = 1
8. 02 = 2
9. Put the hex value in the binary section.  (note, the ASCII will look like nonsense)

Your all set.  Bounce your phone so it gets DHCP from your server and ensure it finds the SIP server.  If you get an error "SIP Server not found" then you either have the IP address incorrect or the SIP Server port incorrect. 

Note: troubleshooting DHCP is very easy with wireshark, just filter for the Bootp.  This way you can see what options it's handing out.  There is also a handy tool out there called DHCPtest
http://blog.thecybershadow.net/2013/01/10/dhcp-test-client/