After upgrade my home server by adding some memory and an SSD, I decided to reinstall my server using Windows Server 2016.
The ISO I downloaded a while ago from Microsoft is 5.5GB big, so it is not feasible to burn to a DVD, since I don’t have a double-layer burner. Although I stocked a hundred DVD/R and CD/R, who is using disk these days?
So I searched online, and found this is post is quite useful. It’s by the same guy – Dan Stolts. One link is on MSDN: https://channel9.msdn.com/Blogs/ITProGuru/Create-Bootable-Windows-Server-2016-USB-Installation-Drive-Step-by-step
Another link is on his own blog site: http://itproguru.com/expert/2016/05/create-bootable-windows-server-2016-usb-thumb-drive-for-installing-os/
Despite one small typo, this is quite authentic. I tried it out this afternoon, it’s easy and quick as long as you understand a bit of DOS command and how to read help. (Be very careful on the drive letter).
Basically in three steps:
- Create and activate a partition on your new USB drive, and format it;
- Prepare the boot sector on this USB drive;
- Xcopy all content extracted from ISO to the USB drive.
The USB drive I used is 8GB, enough for the 5.5GB install image. I like this way because USB drives are reusable. I threw out dozens of optical disks every year, some of them were just used once or never used, I felt guilty when I got rid of them.
Well, this is just some notes on how to prepare PowerShell to manage Azure Active Directory and Office 365. But similar to connecting to AD in Azure, you also need to go through these steps to connect PowerShell to an Azure subscription.
This is quite interesting actually when I put them together. As AAD still has two active environment versions, same as Azure console – Classic and RM – they belong to different logins, a little confusing to admins. Also PowerShell modules need to be installed and updated to enable different cmdlets set in order to manage different products – cloud, non-cloud, 3rd-parties like AWS, etc. So when something is not working, maybe you are in a wrong dimension or Microsoft wants you to update the binary you are using.
One more thing: remember to check the update time of anything posted online, those older than 3 months might be useless.
Telnet is a quite useful connecitivity verification tool, especially during the system set up or troubleshooting. For some reason, mostly security concern, this feature is disabled since Windows Server 2008. But when you want a quick check, it’s really a pain to open the Server Manager and click, click, click… Fortunately we have PowerShell. So here is the one-line command to turn it on:
And another command to turn it off, before you log-off:
Classic, a.k.a. Service Management Model, ASM:
Resource Manager, ARM:
I should have put this handy long time ago. There is situation that we need to know if a special port on a server is listening, then we can see if need to open firewall, etc. So the command netstat is our friend.
Simple way to use netstat is:
>netstat –ano | more
It will show all the listening ports in numerical form, and the process ID that is listening.
Another way is use find:
>netstat –an | find “:3389”
TCP 0.0.0.0:1367 0.0.0.0:0 LISTENING
I will add some Linux command later.
This workaround using the PowerShell, seems fancier than the dozens of click I just did.
One of our clients had recently configured Remote Desktop Services on a Windows Server 2012 R2 OS. Since it was a small infrastructure, all the remote desktop roles were installed on the single ser…
Source: Error “The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license” !!
Source: JOPX on SharePoint, Windows Phone and Windows 8
- Every file which is stored in SharePoint is stored in the SQL Server database as a Binary Large Object (BLOB). SQL database storage needs high IOPS (input/output operations per second) and low latency. This combination means that this is typically expensive storage.
- Around 95% of many SharePoint databases is BLOB data
- It is however possible to take these BLOBS out of the SQL database and store them somewhere else – this is something called blob externalization.
- There are two APIs available in SharePoint for blob externalization – commonly referred to as EBS and RBS
- SharePoint External BLOB Storage ( EBS) – an API which was specifically written for SharePoint Server 2007 and which was shipped with Service Pack 1 of SharePoint Server 2007. EBS is supported by both SharePoint Server 2007 and SharePoint Server 2010. Do note that EBS is being deprecated and is likely to be removed from the next version of SharePoint Server. There can only be one EBS provider per SharePoint farm.
- SQL Remote Blob Storage (RBS) is an API which came available with SQL 2008 R2 Feature pack. It is not unique to SharePoint but is available to any application. You can build your own RBS provider library (and most third party storage optimization tools have done this) and Microsoft also did this by building a provider named the FILESTREAM provider which can externalize Blobs to local storage.
- The SQL FILESTREAM feature can only use local storages. Therefore RBS FILESTREAM Provider has the same limitation. 3rd party RBS Providers do not have this limitation if they are not leveraging SQL FILESTREAM feature. (See FAQ: SharePoint 2010 Remote BLOB Storage (RBS)
- Externalizing BLOBs from SharePoint will not only save you money by moving into tiered storage but will also increase the performance of SharePoint. In a typical real-world collaborative environment Microsoft reports a 25 percent performance increase with BLOB externalization. Check out this white paper for more details – SQL Server RBS performance with SharePoint Server 2010 and StorSimple Storage Solutions .
- Performance improvements increase as the size of files increases. Microsoft research indicates that if files are smaller then 256 KB – SQL storage will out perform, above 1 MB the file system will provide better performance. Check out Plan for RBS (SharePoint Foundation 2010) for more details
- Also remember that when you externalize BLOBs, you architecture might become more complex. After you externalize BLOBs, you must consider the BLOB store in plans for backup, restore, high availability, and disaster recovery. Here, the story can be complex, but doesn’t have to be.
After you install or upgrade the new CA and certificate chain in your environment, you need to verify that all the servers and network devices trust the new authorities. This also applies to the reverse proxy and sometimes it gets little more complicated.
This is a scenario that the client certificate was issued by the new issuing CA. When user tried to access ActiveSync published by Microsoft Forefront TMG, the browser got this:
On the TMG side, it showed a similar error. The description from Microsoft is the same for error 12221 and 12321: The client certificate used to establish the SSL connection with the Forefront TMG computer is not trusted.
But when you checked the chain that installed in TMG, they look fine. Also the client certificate itself is okay. So where could be the problem? First, it is almost sure that the error was given from the listener in the publishing policy in TMG. In the listener, you can choose the client authentication method. The client certificate part is in Advanced Options. There, if you go to Client Certificate Trust List, you will see what the existing setting is. Double check if the listener accepts any client cert trusted by TMG, or only from those checked in the list below. If your new root CA is not there, check it and test again.
What’s next? My test gave me HTTP code 500 - The certificate is revoked with error code 0x80092010.
That’s not possible, right? The TMG has a system policy that allows local to all destination on port 80, it is specifically for CRL communication. So is there anywhere else we can check in TMG? Yes, there is. We can loose the setting a bit on TMG, it is not a good idea for security, but at least we can move forward and verify something further to the CA. Here is the setting that you can uncheck in TMG Console – Web Access Policy – Tasks – Configure Certificate Revocation.
After this, you should be able to reach the site, then focus on the CRL Delta issue in the new CA, according this TechNet article: http://blogs.technet.com/b/sooraj-sec/archive/2013/09/19/activesync-on-some-smartphones-in-this-scenario-iphones-with-client-certificate-authentication-does-not-work-it-works-for-some-other-phones-including-iphones-and-windows-phones-as-well-as-android-phones.aspx
We are going to try this out …