SfB Disabling TLS 1.0/1.1 Guidance

Update 20181107
Microsoft waffles yet again.
https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365








On October 31, 2018, Microsoft Office 365 will be disabling support for TLS 1.0 and 1.1. This means that, starting on October 31, 2018, all client-server and browser-server combinations must use TLS 1.2 or later protocol versions to be able to connect without issues to Office 365 services. This may require certain client-server and browser-server combinations to be updated.
https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365

SfB impact?

At a high level, this requires installing Skype for Business Server 2015 CU6 HF2, applying pre-requisite updates to .Net and SQL, and finally another, separate round of OS configuration updates, i.e. disabling TLS 1.0 and 1.1 via registry file import. It is critically important that you complete installation of all prerequisites, including Skype for Business Server 2015 CU6 HF2, prior to disabling TLS 1.0 and 1.1 on any server in your environment. Every Skype for Business Server, including Edge role and SQL Backends, require the updates. Also ensure that all supported (in-scope) clients have been updated to the required minimum versions. Don’t forget to update management workstations as well.

Background reading:

https://blogs.technet.microsoft.com/cloudyhappypeople/2017/12/22/the-end-of-support-for-older-tls-versions-in-office-365/
And then read part 1 here for more background specific to SfB/Lync and the supportability statements
https://blogs.technet.microsoft.com/nexthop/2018/04/18/disabling-tls-1-01-1-in-skype-for-business-server-2015-part-1/
Part 2 here gets into the weeds a bit on “How To Achieve”.https://blogs.technet.microsoft.com/nexthop/2018/04/18/disabling-tls-1-01-1-in-skype-for-business-server-2015-part-2/Part 3 will be published at a later date.  Woot!

Here is guidance for Lync Phone Edition (LPE):

https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Certified-Skype-for-Business-Online-Phones-and-what-this-means/ba-p/120035 

General TLS1.2 whitepaper:

https://cloudblogs.microsoft.com/microsoftsecure/2017/06/20/tls-1-2-support-at-microsoft/

Here is the Microsoft Exchange equivalent:

Part 1https://blogs.technet.microsoft.com/exchange/2018/01/26/exchange-server-tls-guidance-part-1-getting-ready-for-tls-1-2/Part 2https://blogs.technet.microsoft.com/exchange/2018/04/02/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and-identifying-clients-not-using-it/And big surprise, part 3 to be published later.

Summary

If you or your customer is doing anything with Office 365 hybrid, then you need to be reading all of this and figuring out your next steps.

SQL Change Ports

The Port Change Issue

On a project where the SQL team has a policy of changing the SQL port away from the default of 1433? 

This does not pose a huge problem for your intrepid Skype (or Lync) deployment engineer.  If you are needing to know what to do, and maybe you have, oh, 30 or so front ends to modify, then maybe I can help you out a tad.

The issue is modifying the registry to tell your host server where to go to access the requisite port on the target SQL server.  As it turns out, I had to remember this, as it has been a bit since I had to last do this task. 

The Simple Fix to the Simple Issue

Luckily for you and me, it seems that every copy of a Windows operating system I looked at for this post (Win7, Win8, Win10, Server 2008+) have a utility in \windows\system32 called cliconfg.exe.  You can read up on that utility here.

A wonderful tool.  Here is it in Windows 10 form.  Which looks the same as Win7, so I think they will all pretty much appear to be the same. Actually, the Win7 version has a different set of window frames, so the appearance is more rounded instead of the ugly-ass Win10 metro crap.  But I digress.

What we need to do is select the Alias tab…the select Add.

For the purposes of this exercise, I need my system to talk to my SQL server (FQDN = sqlalwayson-a.tsoorad.net) on port 49001.  So, you set it up like this and then say OK.

Follow up that OK with an APPLY and your newly modified operating system will for thereafter talk to SQL server sqlalwayson-A.tsoorad.net on port 49001 vice 1433.  Simple.  Easy.  Works well.  Less filling.  Man, I am thirsty!

But Wait!  What if…

…you have like four user pools, and they all need to talk to the same monitoring server, but different archive targets per pool?  And what if there are like 30 front ends that need this modification, and every time you type this stuff in there is the possibility of spelling errors that mean system failure.  Now, I am sure there is some folks out there in techie land that are starting to chant “PowerShell!  PowerShell” -  but in this case, I am going to ignore them, and simply export a registry key, and then incorporate that into my server build process – which can be PowerShell-ized if you wish.

Here is the registry key to export.  HKLM\software\microsoft\mssqlserver\client\connectto

In my project, we had four SQL AG clusters, each with two nodes, a cluster name, and the AG name; all that needed to resolve by DNS.  So, our registry key looked somewhat like this: 16 entries with AG, cluster, node1, and node2 per supporting SQL cluster.  We then simply imported that into each server at build time.

Summary

The SQL mavens might well change ports on you.  If they do, there is an answer in form of cliconfg.exe.  If the scale is a tad larger than manual typing will cover, you can regedit your way to success.

YMMV

WebConf modalities not working for internal users after server patching

This falls into the “oh wonderful” category…

https://technet.microsoft.com/en-us/library/security/ms16-065.aspx breaks Office Web Apps for internal users.  External users seem to be unaffected.

Conferencing modalities no longer function in Lync Server 2010, Lync Server 2013, or Skype for Business Server 2015 after you install Security Bulletin MS16-065Here is a fix workaround:

https://support.microsoft.com/en-us/kb/3165438

And people wonder why I always advise waiting 90 days or so before patching Lync and SfB host servers.

The documented update in the article is KB3156757, but the actual KB installed was KB3156756.  Which also is associated with MS16-065.

YMMV

Windows PKI SHA-1 to SHA-2

(How do you hear me now?)

Thanks go to fellow CDW co-workers Dean Sesko, Russell Despain, and Keith Crosby

 

What is the issue here?

Basically, the issue is that SHA-1 for PKI is going away in favor of SHA-2, and you WILL have customers that need help with this.

 

Reference:

• https://www.networking4all.com/en/ssl+certificates/ssl+news/transitioning+from+sha1+to+sha2/
• http://blogs.technet.com/b/askds/archive/2015/04/01/migrating-your-certification-authority-hashing-algorithm-from-sha1-to-sha2.aspx
• https://technet.microsoft.com/en-us/library/cc751157.aspx
• http://www.entrust.com/sha-1-deprecation-on-to-sha-2/
• http://security.stackexchange.com/questions/73491/how-will-sha1-deprecation-affect-sha1-roots-in-os-browser-trust-stores
• https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
• https://www.digicert.com/sha-2-ssl-certificates.htm

 

AND…?

Any Microsoft supported operating system, properly patched/upgraded, and any Microsoft supported application, again properly patched/upgraded, will support SHA-2 PKI certificates.

 

Reference:

• http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

…there are some caveats: notably around XP and Server 2003, and oddly, Server 2008.

Reference:

• https://support.microsoft.com/en-us/kb/968730
• https://support.microsoft.com/en-us/kb/938397

So, there is not an issue with Microsoft supported products; the issue is with BYOD and Microsoft making a HUGE effort to support alternative browsers and operating systems. And those browsers and operating systems are fixing on deprecating their support of SHA-1.

 

Reference:

• https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
• http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
• http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

However, there are going to be numerous AD internal CA’s out there that are issuing SHA-1 certificates, and depending on how the environment is configured, the customer will need to renew their application certificates for internal use. Logically, it makes sense that the desirable outcome of renewing the application certificates is that the issuing PKI be SHA-2.

CDW AD resident experts advise instantiating a new Root CA, and if needed, a new subordinate CA for issuing SHA-2 certificates. But, you know those pesky customers, they may not want to do this. Which would call for modifying the existing structure to hand out SHA-2 vice SHA-1.

 

Reference:

• https://technet.microsoft.com/en-us/library/dn771627.aspx

Experimentation over the last several hours has revealed the following:

• Migrating the existing SHA-1 CA went just fine.
• The new SHA-2 Root Certificates updated almost immediately into the Trusted Root

• I was able to request new SfB certificates and they were issued by the CA based on the new 3DES/SHA-2 root
  • However, the host server was not able to chain them up into the Trusted Root.
  • I rebooted.
  • I ran GPUpdate –force
  • I rebooted.
• After waiting overnight, THEN the new certs chained up properly. Why this delay in chaining to the new Root I have no idea. I suggest that if you do this for real, that you do the work on one day and then plan on waiting for at least 8 hours before attempting to get new certificates and expecting them to chain up to the new root.

Testing:

After updating the internal certificates on my SfBSE to a new SHA-2 I successfully tested

• using Win8.1 and Win7sp1
  • IE 11
  • Chrome Version 43.0.2357.134
• Surface Pro 2 (8.1) IE
• iPad (iOS 8.0.2) Safari

Firefox 39 fails – due to it not liking the root cert – why is FF so blinking difficult? Why does it have to have its’ own key chain? The O/S has the root cert! It does this same shit when installed on *nix. After manually importing my new root cert, it worked just fine.

• SIP Phones.  I had to restart services (stop-cswindowsservice start-cswindowsservice) AFTER I changed the certificate to the new SHA-2 certificate before my AudioCodes 420HD and Polycom VVX-600 would log in.  Why, I do not know.

 

The SfB/Lync Connection!

You may have been wondering why *I* am worried about this.  Well, on literally every project with which I have been involved over the last few years, they all had *nix and Mac workstations, along with loads of iPhones, iPads, *nix tablets, droids, surface tablets, and here and there the odd Windows phone.  And, you have to know that, in most cases, all of these were attached to an internal corporate wireless.  And in some cases, the internal wireless was dropping these devices into the production network, which put them in a position to being able to directly contact Lync/SfB resources on internal servers, that, for the most part, had a PKI certificate from an internal CA.  With SHA-1.  You knew it had to be simple, right?

Any input to solving/addressing the observed delay would be most welcome. I, for one, totally expected to have the new certificate chain immediately – the appropriate root cert was in place!

YMMV

SSRS into existing default instance

Are you trying to install SQL Server Reporting Services onto an already built default or named instance of SQL?  Does it error out telling you that the instance already exists and you need to choose another, and you don’t wanna choose another?

Then you might want to read this.  Yes, it is for a really old version of SQL, but hey, it works.  I just tested this on SQL 2014.

Run the below command at the Windows command prompt to start SQL Server setup on the active node.  Make sure to run this command after changing the root directory of the command prompt to the location where you have placed the SQL Server setup files.

Setup.exe /SkipRules=StandaloneInstall_HasClusteredOrPreparedInstanceCheck /Action=Install

This bypasses the SQL install logic checks.  A downside is that the setup routine skips the auto-magic SSRS Native mode configuration. You will need to do a manual configuration of the SSRS using the Reporting Services Configuration Manager.

This is no way implies that if you do a SQL Availability Group, and put SSRS on both (or all) nodes, that the SSRS is now in a DR state.  In fact, some really useful reading for doing the DR process with SSRS in this posture can be found here: 

https://msdn.microsoft.com/en-us/library/hh882437.aspx

YMMV

Asus Mobo & Server 2012 R2

Did you need to update your lab server?  Do you run a high-end gaming or media platform and need a boatload of RAM so you obtained an Asus mobo so you can have 32 or 64 GB of RAM?  Did you decide to go with a Windows Server 2012 R2 as a workstation host for the goodies you get with that?

If so, then I will make the guess that you discovered that the Asus-supplied driver disk claims that your operating system is not supported.  Horse pucky says you – with Windows 7/Server 2008 and Windows 8 (and 8.1)/Server 2012 (and R2) the core of the operating system is much the same and drivers will work on both, right?  Very frustrating to know something should work and be turned away by a mechanism to save the consumer from themselves.

This is now the second time I have run into this little gotcha; and for the second time, I worked around the issue the same way.  I suppose you could go find all the drivers and try to load them individually; however, one of the problems is that the LAN driver is a toughie.  Downloading the drivers and suite software direct from Asus runs you into the same issue – “your operating system is not supported” and you start questioning your sanity and direction in life.  My first experience with this was with Server 2008 R2 and an Asus P8z68 board.  This weekend I ran into this issue using a Asus Sabertooth X79 board and Server 2012 R2.  Specifically, I am using this mobo here.

What is the issue?

The *.ini files don’t include a proper operating system identifier that tells the driver/utility disk that it is OK to install for Server 2012 R2.  Very frustrating knowing that the drivers and whatnot will work just fine – well, there is an issue with the on-board Ethernet controller (and Intel 82579v) that the Server 2012 R2 doesn’t like – but I have a fix for that as well. 

A little error comes up with the audio drivers, but in my case, this is a headless VM host, and I am not too worried about that aspect of installing.  As it turns out, the audio driver install routine pitches and error, but then continues to install and works just fine.

The Fix

OK, so what do you need to do?  First, copy the CD to somewhere on a writeable drive.  Then find EVERY *.ini file in the resulting file structure.  You should end up with something like this:

and here is the end of the list…

Yes, that one line reads “264 File(s)”  that is a lot of them!  But, we do want to be successful, yes?  Note also that the very FIRST file listed is not “AsusSetup.ini” or “AsusSetup64.ini” – this is important. 

Let’s Dive In!

Cannonball, Can Opener, perhaps a graceful Swan dive or something you would see off the 10 meter board in a formal diving competition, pick your poison.  What you need to do is modify every last one of those ini files with the name “asussetup.ini” or “AsusSetup64.ini” – not the worlds best task for a Friday night, but you do want this to work, yes?

FWIW, I used this tool here.

Start by looking at the file \bin\Ascdinst.ini in your favorite editor, and find this piece:

WNT_6.3H_64 = Win81_64  --- Without getting too deep into the weeds, this line reads “Windows 8.1 Home Edition”

What you need to do is realize that this:   WNT_6.3I_64 = Win81_64 represents Server 2012 R2.

If you are trying to do this little routine with Server 2012 (why?) or Server 2008 (or R2) (why?) you can use these lines:

Server 2012 R2: WNT_6.3I_64 = Win81_64

Server 2012: WNT_6.2I_64 = Win8_64

Server 2008 R2: WNT_6.1I_64 = Win7_64

Server 2008: WNT_6.0I_64 = Win7_64

For those of us who are font-challenged, or maybe just a bit dim or blind, the “I” in those strings is a capital i.

What is going to happen here is that the installer is going to read the installed operating system as WNT_6.3I_64 and equate that to win81_64, which is supported for install.

At any rate, in your favorite editor, you want the appropriate section in the ascdinst.ini file to read thusly:

WNT_6.3P_32 = Win81_32
WNT_6.3P_64 = Win81_64
WNT_6.3P_32_MCE = Win81_32
WNT_6.3P_64_MCE = Win81_64
WNT_6.3H_32_MCE = Win81_32
WNT_6.3H_64_MCE = Win81_64
WNT_6.3H_32 = Win81_32
WNT_6.3H_64 = Win81_64
WNT_6.3I_64 = Win81_64

Once you get that first one done, the asussetup will be happy.  The other 263 files need to be done also to enable the individual components to install properly.  Happy grepping!  or, Happy notepad ++’ing, or however else you choose to do it. Yes, I know I said that some of the files don’t need to be done, but you never can tell which.  Actually you can, if the WNT_6.3H_64 line is not present, you don’t need to worry about that ini file.  But, do you really want to mess around with looking at each file?  No, I did not think so.  Pick a tool and use it.

As a nit-picky technical note, for your purposes, you really don’t need the WNT_6..3H_64 line at all, so you can just grep every ini file on the disk, and if it finds the WNT_6..3H_64 line in the file, replace it with WNT_6.3I_64 = Win81_64. Which *I* did not do, because there is always the chance that I might, for some reason known only to Microsoft, need to install the Windows 8.1 Home Edition on my 64GB Lab server.  You never can tell.  I might come down with a severe case of stupid one day.

LAN Driver

In a twist of technicality that I have no desire to attempt unraveling, Intel does not produce a driver for the 82579V GB Ethernet Controller that supports Server 2012 R2.  Don’t ask me to elucidate, I said I don’t know.  But, what remains is that even when you work your way through 264 different ini files doing the above routine, the LAN driver on the disk is going to barf on you because it doesn’t like Server 2012 R2.  Again, I don’t know why.

What I do know is that you can do the Device Manager thing, and tell Windows itself to install the 82579LM driver, which works splendidly.

If you go here: https://downloadcenter.intel.com/download/23073 and actually read the fine print, you will find this:

NOTE: The following devices do not have driver or software support for Windows Server 2012 R2:
- Intel® Ethernet Connection I217-V
- Intel® Ethernet Connection I218-V
- Intel® 82579V Gigabit Ethernet PHY

So, it would appear that the 82579LM driver is going to have to suffice. As you can see, I have plenty of traffic on the network, but as a fraction of the speed provided by the NIC, it doesn’t even make a pimple on the radar screen…

When we do a little file transfer to get a feel for actual speed, it certainly looks like we are getting GB speed.

 

Summary

At this point, remember that the first file you do is different from the rest in the terms of naming convention.  All the rest you need to worry about will say asussetup*.ini.  There is a bunch of language ini files; I don’t think you need to worry about those, unless of course you know something about language files being bit-specific that I don’t know.

Oh, BTW, this Asus board rocks.  Although I am not sure I will ever need all 30 USB ports.

YMMV

Duplicate IP error

Just ran into a little something I have not seen in a long time. Building edge servers with Windows Server 2012R2 and the external NIC kept coming up as duplicate address. Doing all the cross checking showed that the server had only two interfaces and that they were configured properly. Turns out that this little gem from 2008 R2 days is still valid:

http://social.technet.microsoft.com/forums/windowsserver/en-US/d7bda315-6366-4e0a-bdcf-dc875ff6963e/win-2008-r2-servers-will-not-connect-to-network-says-duplicate-ip

The firewall doing the NAT to the public IP was ASA. The registry change for disabling gratuitous ARP fixed all of the my edges.

This might be of interest also:  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028373

YMMV

DHCP option 002 for Lync phones

Maybe I have been living under a rock… but I have been doing this manually… finally found a nifty chart so I can stick it in OneNote instead of having to figure it out each time – complete with instructions on how to calculate manually.  I take no credit, this is blatantly cut from a Cisco website source.

Standard Pacific time is GMT -8. This is a simpler way to calculate GMT with negative values:

1. The number of seconds equivalent to - 8 hours = - 8 hours * (3600 seconds / hr) = - 28800 seconds.

2. With a scientific calculator, enter the number -28800 in the calculator with decimal values. The (-) sign is very important. In order to get the negative sign in front, press the +/- key.

3. Choose Hex. This gives you FFFFFFFFFFFF8F80. This is because, by default, the calculator has Qword enabled.

4. In order to get rid of the extra Fs, choose Dword. This produces the value FFFF8F80. If you do not have this option in your calculator, use only the first eight digits from right to left.

5. The value placed in the DHCP pool configuration now becomes option 2 hex FFFF.8F80.

 

Table of Conversion of Different Offset Times into Hexadecimal

This table gives the conversion of the different time zones around the world. The hexadecimal values are set to have a fixed length of 32 bits as specified in Option 2 of the DHCP RFC 2132. For a world timezone map, refer to World Time Zone Map.

GMT offset (in hr)	GMT offset in seconds	GMT offset in Hexadecimal
0	0	0000.0000
+1	3600	0000.0E10
+2	7200	0000.1C20
+3	10800	0000.2A30
+4	14400	0000.3840
+5	18000	0000.4650
+6	21600	0000.5460
+7	25200	0000.6270
+8	28800	0000.7080
+9	32400	0000.7E90
+10	36000	0000.8CA0
+11	39600	0000.9AB0
+12	43200	0000.A8CD
-1	-3600	FFFF.F1F0
-2	-7200	FFFF.E3E0
-3	-10800	FFFF.D5D0
-4	-14400	FFFF.C7CD
-5	-18000	FFFF.B9B0
-6	-21600	FFFF.ABA0
-7	-25200	FFFF.9D90
-8	-28800	FFFF.8F80
-9	-32400	FFFF.8170
-10	-36000	FFFF.7360
-11	-39600	FFFF.6550

Example

Pacific Time Zone = GMT –8

60*60*8 = 28800.  Change sign. Now we have –28800.

Click the Hex button.  Now we have

Click the DWord button.  Now we have

Here is the value in the DHCP Server Options. Note that we take the DWord value and append “0x” to it.

YMMV

Install Lync 2013 prerequisites script

Faced with having to install 18 servers, 8 gateways, and 2 SBA’s for a upcoming project, I went looking for some scripting help to get at least SOME of the work done semi-automagically…

Fellow MVP Pat Richards has developed an awesome script to install Lync Server 2013 prerequisites, SQL Express, Office Web Apps, and a partridge in a pear tree.

I recommend that you take a look at this wonderful piece of work.  You can find it here.

YMMV.

Veeam and Volume Mount Points & RDM

It would appear that Veeam does not play well with volume mount points.  At a recent project, we migrated into a new Exchange 2010 environment using volume mount points attached to c:\volmtpt – Veeam would see the empty folder, but never the contents.

We were providing the the raw drive space with RDM.  So we tried the same drive space, but mounted as a direct drive.  Veeam could not see that either. Veeam support forums hinted that RDM may or may not work – apparently depending on the phase of the moon.  There are some folks who claim to have it working – but not me.

In the end, we went with raw drive space vmdk.  Now it works as expected.  But what if you don’t want 24 drive letters?  Or even more than 1?  Windows Server Backup, in the same scenario had no issues with the mount point construction.

WASSUP WID DIS?

YMMV

Static MAC addresses in Virtual

With the advent of more and more virtualization, and virtualized appliances, you may run across a situation where you need to assign a static MAC to a specific VM. Some virtual appliances use the MAC of the virtual NIC to figure out their licensing, so this would be a perfect example of needing to set a static MAC for the virtual machine. If/when the image moves inside the resource pool or is manually moved to a different host, if the MAC is not static, there is the specter of the VM losing the existing MAC and having a new one assigned. At this point the virtual appliance may lose its’ ability to use the license that was keyed to the MAC on the original load. The answer is to set a static MAC for that virtual machine. As a side note, you may also need to pay attention to doing this license process with only ONE NIC assigned to the VM.

For the VMware addicts:

http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_41/esx_server_config/advanced_networking/c_setting_up_mac_addresses.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=219

For the Hyper-V folks:

http://www.solution-soft.com/whitepapers/Microsoft-VirtualServer-StaticMAC/Microsoft_Hyper-V_Static-MAC-address.htm

For the Server 2012 Hyper-V users, the actual screens change a bit… here is a zippy screen shot.

YMMV

WNLB not working on local subnet

I ran into a very odd situation today.  Now, I know that there are those out there in cyberland who will have seen this before, but I have not, and on the odd chance that it might help you, I post this.

Situation

Doing WNLB, using VMWare hosting the WNLB servers.  Therefore, according to VMWare we should be using multicast.  So we did.  And swiftly noticed that other servers on the local VLAN could not find the WNLB address.  In fact, we noticed that the switch itself could not ping the WNLB address.  Devices on OTHER vlans could ping the WNLB.  WTF?!   Double-check the setup and redo the static ARP on the switch with this:

ARP 10.1.8.75 03bf.c0a8.0164 ARPA

Here is what it looked like AFTER we did the proper static ARP configuration on the switch…

Notice that a tracert is showing that even the simplest action is pushing the packets at the local gateway. 

We are using the following switch hardware:

Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-ENTSERVICESK9-M), Version 12.2(54)SG, RELEASE SOFTWARE (fc3)

System image file is "bootflash:cat4500-entservicesk9-mz.122-54.SG.bin"

cisco WS-C4948-10GE (MPC8540) processor (revision 5) with 262144K bytes of memory.

Processor board ID FOX092101VW

The Fix

After going back and forth, including rebuilding the WNLB configuration, we realized we were dealing with a multicast capable switch.  Having nothing to lose, we did the following on the switch:

no ip multicast-routing

wala!  Now we can resolve the WNLB, ping it, tracert to it, and actually access services on the member servers.  Oddly, I had a colleague with a similar issue at the same time.  Their situation was resolved by using the arp IP MAC arpa command not only on the switch the WNLB connected to, but all distribution switches and the core of the stack also.

YMMV

E2010 EMC cannot read local server

The Issue

Opened the EMC on several E2010 servers today.  Was rudely told that the EMC could not contact the local server.  A reboot fixed the problem, but I don’t like that.

I found this little routine here.

1. make sure IIS WinRM extension is installed
2. open powershell and run command : WinRM Quickconfig
3. Open IIS go to Powershell virtual directory and check that SSL in disabled and authentification is set only to Anonymous
4. Open Windows powershell modules
5. run Remove-PowershellVirtualDirectory command
6. run New-PowershellVirtuallirectory command
7. IISreset

I did not have to do the entire thing in my case.  I did, however, check each and every e2010 (all 14) in the environment.  NONE of them had the WinRM installed.  All of them had the PowerShell vDir with anonymous disabled, but not requiring SSL.

What’s up with that?  I checked the e2010 on server 2008 R2 prerequisites and the IIS WinRM is not listed for any role – which explains why it was not present on any of my servers.

The Fix

So, my final resolution was:

1. Install IIS WinRM Extension
2. Enable Anonymous on the PowerShell vDir

YMMV

Maximum Number of names in a SAN Extension

In what is sure to be a long standing record (of sorts) for me (and maybe only me) – I just submitted a CSR to a public provider with 53 domains in the SAN field.  This raised the question:  “how many entries or names can be in that one field?”  I know there has to be some sort of limit. 

Handy Dandy, we had a TMG guy in the room, so we asked him.  While he did not know off the top of his head, he did have an answer in mere minutes (where I had googled for about 10 and found squat).

http://social.technet.microsoft.com/wiki/contents/articles/3306.aspx

So, now we know the field is defined by a database, that a Windows PKI CA is limited to 4k of names, and that somewhere around 150 25 character domain names eat up just under 4k.  By extension, we can assume (and we know what that means) that the Public cert providers are following the same RFC and that they will have a similar limit.

How about that?  An answer to a question you did not know you had!

YMMV

Static Routes in Server 2008 R2 Not Consistent

The Issue:

Onsite with a customer setting up the initial E2010 DAG MBX servers.  In constructing the MAPInet and REPLnet NICs on each server, we noticed that the static routes were not behaving as expected.

We checked the commands for establishing the static routes and how the NICs were setup.  We were consistent across the board, on both subnets and sites.  As an example, here is what we were using from the one site:

route add 10.12.93.0 mask 255.255.255.0 10.1.26.1 if 15 –p

This resulted in a 80% failure rate at that one site to establish a static route for the REPLnet traffic (for you score keepers, this equates to 40% failure across the environment).  Obviously, we cannot continue with DAG construction until this is resolved.

The Fix

netsh int ipv4 add route 10.12.93.0/24 “replnet” 10.1.26.1

Using the netsh method resulted in 100% success at not only putting a persistent route into place but actually having it work!

Thanks to http://fixmyitsystem.com/2010/10/adding-static-route-using-netsh-and.html for having a nice little article on this subject.

YMMV.

2008r2 and TMG and VPN = NO!

The Issue

Having just ran around the world on this, it would appear that even with TMG SP1, Server 2008R2 does not allow TMG to do simple PPTP VPN. I foolishly thought I would insert the VPN service into my lab as a quick test.  All my web publishing rules continued to work flawlessly; Lync Web Components; NAT for my Lync, Exchange 2010 publishing – everything worked except VPN.

If you are intensely interested, the VPN connection would be made, but no traffic was allowed to flow.  Don’t know why, and at this point I don’t much care. 

The Fix

I fixed it by building a new server on 2008 SP2.   If you are doing a project that includes TMG and want to have the same TMG provide VPN, you should most likely think about it and lab it before you continue.

Hopefully, someone can point out the errors of my ways and show me what I did wrong.  YMMV.

Open Services applet in Standard Mode

Ever since somebody at Microsoft decided we needed the services.msc applet to open in “extended” mode, I have been clicking on “standard” to get the view I wanted.  This last week I finally got fed up with this, and decided to do something about it.  As it turns out, this is not the easiest thing to change.  Apparently, us poor users are not allowed to change the behavior for the named services.msc.  We are not worthy. 

What you have to do is author a new named instance – and of course remember to use that one.  I was unsuccessful at renaming, deleting, or otherwise removing the original services.msc.  I am sure there is some method to do so, but I was unwilling to dink too much with an operating system that was working before I messed with it.  YMMV.

Here is what I did: (the example is using an x64 Win7 O/S, but it works equally well for Server 2008, and I imagine, Vista (why are you using that?).

Go to c:\windows\system32 and locate the services.msc applet.  Right-click it and select “author.”

When services opens, click File | Options as shown.

Now, change that console mode to “author.”

Say OK to this…

Change the view to standard…

Now, save this to a name and location of your choosing…

Now when you go to a command line (or in my case about 90% of the time a powershell prompt), and type in jmwservices.msc, I get this “new and de-proved” services applet in standard mode.  I suppose you could mod the original references to the new applet if you want to get fancy.

Enjoy!

dot net v4 breaks iSCSI from NetApp v6.3sp2

 

edit 15 May 2011

Some feedback from NetApp is that this will work *IF* the SDW and NET3.51 are installed first before putting NET 4 into place.

---

In our environment, .net v4 also appeared to block installation of BES 5.0.3.  My support chain contacted NetApp engineering, who says that .net v4 is supported.

FWIW, we are using Server 2008 R2 SP1, with all updates (straight install), VMware ESX and ESXi v4, UCS hardware.  I do not know the NetApp filer model/version.

What we saw:  after install of the base O/S, we installed the NetApp v6.3sp2 LUN driver.  Everything appeared to work failry well, until we committed to the LUN and the connection process started.  All we ever got was the 120 second time out.  On the back end, the LUN looked connected at the NetApp, but on the server, there was nothing.  Attempts to reconnect at that point resulted in being told that LUN was already dedicated.

Removing .net 4 components from the server allowed full, normal, LUN connection.

 

YMMV

Server 2008 R2 SP1 AD errors

At a customer site doing some due diligence on AD health.  DCDiag from the first Exchange 2010 CAS server against the FSMO holder failed on the DFRSEvent and KCCEvent checks with an event ID of 0x6BA.  Running the same test on the FSMO holder (we need to extend the schema folks!) failed with 0x6BA also. 

Once we got the first issue reduced, then another popped up on both the FSMO holder and the DCDiag from the Exchange CAS server:  0x8000043B

Doing a little googling revealed this blog entry that got me started on fixing the issue. However, this blog entry clearly stated that the “Remote Service Management (RPC)” was the culprit. 

Enabling this rule in the DC’s firewall did not help me; so I started with all the rest that looked like they might be what I was looking for.  Not the most scientific method, but my reasoning was that it was better than turning the FW off entirely.  Also, all other data I could find for this issue all pointed back to the one blog – that guy should be charging for plagiarism!  For my situation, we had to enable this other rule also:  “Remote Administration (RPC)” as shown. 

At this point, DCDiag /s:fsmohost completed so quickly you would have thought the entire thing errored out.  Instead, what it did was pitch the KCCEvent event ID:  0x8000043B.  Not good, I still need the FSMO holder to behave so I can extend the schema (amongst other tasks…).  After wading through more googles, the fix to this second layer of error was:

dcdiag /fix

wala!  Nice clean dcdiag runs from both the FSMO holder and the exchange servers. 

WS08R2 Standalone Root CA

High level instructions for installing a Standalone CA

NOTE:  If you have an Enterprise or Datacenter edition server, the preferred install will be an Enterprise Root.  If you have only Standard Edition WS08R2 Server, then you are not able to install an Enterprise CA and you will have to do a Standalone Root CA.

 

Start with a Windows 2008 R2 server. I used a DC, but there are some who think that is an issue. You should choose what you think works best for your environment or what matches your security model. If you choose to do a Standalone RootCA, then you will need this entire document to include the CLI work at the end.

1. Open servermanager

2. Add roles

3. Choose Active directory certificate services

4. Say next on the Intro screen…

5. Select as shown here:

6. Choose appropriately here. I recommend the Enterprise, it really is easier. However, you can choose Standalone also.

7. Choose Root

8. Choose new key

9. Setup like this:

10. You can rearrange the name as appropriate… take note of it though!

11. I choose to use a LONG period of time… I don’t like to have to renew certs more than I have to…your security paradigm may require you to keep this figure below the default of five years.

12. Accept these defaults… you can change them if you wish…if you change them, be sure to document the change from the default.

13. The webserver setup is so that you can get certs if you are authorized. Exchange UM,OCS, Lync, SQL, and SharePoint come to mind.

14. Because I let the wizard choose for me, these options were filled in for me and will support what I need for the aforementioned applications.

15. Install

Total install time was less than 15 minutes.

16. If you chose to use a standalone edition, then you will need to publish the resulting trusted root cert into Active Directory…

Microsoft Windows computers and some devices are automatically configured with some well-known third-party root certificates. However, if you are using your own PKI, you need to install the root certificate. There are various ways to achieve this, including the following methods:

• If you are using a Microsoft Enterprise root certification authority, the root certificate is automatically installed on computers in the forest, using Active Directory Domain Services.
• If you are not using a Microsoft Enterprise root certification authority but want all computers in the forest to automatically trust the root certification authority, you can publish the root certificate in the Enterprise Trust Store, using Group Policy or the Certutil command.
• If you not using a Microsoft Enterprise root certification authority and want only groups of computers in the forest to automatically trust the root certification authority, you can publish the root certificate to domains or organizational units (OUs) using Group Policy. Only computers that have the Group Policy applied will automatically trust the root certification authority. Add the root certificate to the Group Policy object Trusted Root Certification Authorities under the Public Key Policies folder for the Computer Configuration container.
• If you are using Microsoft Certificate Services with Internet Information Services (IIS), you can request and install the root certificate with the Web enrollment service.
• You can request and retrieve the certificate using the Microsoft Certreq command-line utility.
• You can export the certificate to a file and import it if exporting the public key is enabled within the certificate.

17. To accomplish this using certutil.exe:

Run the following commands to register the digital certificate of the Standalone Root CA and its CRL in Active Directory:

certutil -f dspublish <CA_Cert_File_Name> RootCA and certutil – f -dspublish <CRL_File_Name>

The files <CA_Cert_File_Name> and <CRL_File_Name> are located in the folder %SystemRoot%\System32\CertSrv\CertEnroll

You don’t have to do the CRL but it does make things go smoothly when the host server starts looking for the CRL and can find it because you did publish it….

If you use a standard edition with Standalone Root CA, then you will need to do this command to allow the CA to issue SAN certs:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

One additional thing you can do is to change the certificate issue period from the default 1 year to something a little more lengthy. Using regedit, goto:

HKLM\system\currentcontrolset\services\certsvc\configuration\<CAname> – where CAname is whatever you called the CA in the previous steps.

What you want to do is modify the “ValidityPeriodUnits” as shown here.

 

If you followed things all the way through, you have a Standalone RootCA, with a trusted root cert for a period of 20 years, the trusted root is published into your AD DS (along with the CRL), individual certificates can be SAN/UCC, and the issued certificates will be for a two-year period.