Category: Active Directory

Installing the AD DS role onto a Azure virtual machine? Creating a Domain Controller in the cloud? Are you sure you want to do this?

For all Domain Controllers you create on an Azure virtual machine, in addition to the system OS disk (C:\) you MUST add a dedicated disk and ensure thatyour AD DS install wizard or script uses this dedicated disk as the location for both the Active Directory database (NTDS) and the replicated system volume (SYSVOL) during the Role installation.

IMPORTANT: For this dedicated disk ensure that the ‘Azure Disk Host Cache’ is set to NONE

Failure to do this risks the corruption of your Active Directory database.

“Data disk drives do not cache writes by default. Data disk drives that are attached to a VM use write-through caching. Write-through caching makes sure the write is committed to durable Azure storage before the transaction is complete from the perspective of the VM’s operating system. It provides durability, at the expense of slightly slower writes.

This is important for Windows Server AD DS because write-behind disk-caching invalidates assumptions made by the DC. Windows Server AD DS attempts to disable write caching but it is up to the disk IO system to honor it. Failure to disable write caching may, under certain circumstances, introduce USN rollback resulting in lingering objects and other problems.

As a best practice for virtual DCs, do the following:

Set the Host Cache Preference setting on the Azure data disk for NONE. This prevents issues with write caching for AD DS operations.

Store the database, logs, and SYSVOL on the either same data disk or separate data disks. Typically, this is a separate disk from the disk used for the operating system itself. The key takeaway is that the Windows Server AD DS database and SYSVOL must not be stored on an Azure Operating System disk type. By default, the AD DS installation process installs these components in %systemroot% folder, which is NOT recommended for Azure.”

Of course end of support does not mean your sync tool of choice will stop functioning – it will happily continue to function, but an upgrade will be needed to ensure it remains in support from next year onward.

So get your upgrade boots on and get Azure AD Connect working which is the replacement for any of the previous sync tools and was released in 2015, the link above has further links for an in-place or swing upgrade – whatever floats your boat (in reality choose the method that suits your organisation, also test it first in non-Production!!!)

Azure AD Connect

Azure AD Connect essentially replaces any of the following you might still be running:

Dirsync

Azure AD Sync

Azure AD Connector

FIM 2012 R2

So seriously consider upgrading this side of Christmas, and not next Easter. You have been informed!

Like this:

You’ve finally got rid of those Windows Server 2003, you’re ready to upgrade your AD DS Functional Levels to either 2008 or 2012. Now you finally can and want to activate the recycle bin feature in AD (it wasn’t possible while you still had 2003 R2 DC’s running). The recycle bin feature is stored in the Configuration Partition of your Forest:

This is presumably a location for storing any new features to come. Ok, first it’s nice to check to see if the AD Recycle Bin is already enabled or not, type in:

Get-ADOptionalFeature-filter *

Get-ADOptionalFeature

Note how there is nothing between the {} for ‘Enabled Scopes’ – this means it is NOT enabled. IF it was you would have an entry in here just as it shows in the 2nd screenshot below. To enable it, is is simply this command:

Click Y to confirm and the change is made. Now check the Optional Features setting again, type in:

Get-ADOptionalFeature -filter *

AD Recycle Bin enabled

Test it out. Go on, you know you want to. Delete some objects & recover them (not in Production of course, cause that would be plain silly!). See what attributes are recovered and report back if you wish.

First I’d like to thank all those who have visited my blog, and especially those who have commented or provided feedback. I really do appreciate it, my stats have been steadily trending upwards which encourages me to share more.

Here I quickly outline my blogging plans for the new year:

More car stuff – by far the most popular post on my blog (by hits/month) is my post on the engine pump failure on my Vauxhall back in 2008. The blog post is here and was posted back in late 2010. I still have said Vauxhall and also have a Zafira, i’ve done bits of work on both and will post updates soon.

More technical stuff – this is both my job and passion, so expect lots more. Hopefully I’m aiming to restart my beginners Server 2008 courses, for Server 2012 of course – both online and classroom based. I’ll be covering AD, Exchange, SharePoint, SQL and PowerShell in lots more detail. Oh and lots on Windows 10 as I march on with my Technical Preview.

Birmingham – the city I live in. There is a tonne of stuff I wish to share, from activities through to infographics. What’s good, what could be better and in the words of Oliver Queen I must do what i can to “save my city” in these years of budgetary crises.

Personal Computing – the prevalence of the internet, gadgets, storage and phones means everyone is creating and using data. This is critical data (photos, tax information, licensing, bills, banking, passwords) and I’d like to share how I both store it (with resilience) and secure it (with confidence). This is domestic technology, not corporate.

Trading & Economics – another passion of mine. I will start to share my trading strategy, my actual trades and advice & tips on how to get started and crucially how to create the correct mindset for this. Mental toughness required. Although I concentrate on Forex i’ll be dipping into wider issues such as banking and personal finance where relevant.

CVs/Resumes, Job Hunting, Scam Hunting – as per usual I’ll continue along this path, the 2nd most popular blog post on my site is the CV site one found here. Exposing scams and helping people in their efforts to better their future prospects is something I love doing.

Islam– as my faith is currently under constant attack I believe it a responsiblity to add my input as and when I feel it may improve someones knowledge on an issue. I often find the basis of prejudice is lack of knowledge, educating people and doing it the right way counters bigotry.

There you go, some simple plans for 2015. The good Lord willing I hope to accomplish all of these.

In an effort to reduce SYSVOL bloat and replication across Domain Controllers (DCs) consider using DFS Replication (DFSR). A bigger reason however is that FRS is no longer supported in Server 2012, so if you plan to upgrade DCs to Server 2012 – then you must do this first. Want a third reason? If you are using Read Only DCs (RODCs) and are still on FRS it is easy for the SYSVOL on the RODC to become out of synch with other DCs; better still in Server 2008 R2 and above DFS-R ensures that the RODC SYSVOL can never be modifed.

DFS-R simply provides better and more efficient synchronisation than the old world File Replication Service (FRS). Prior to proceeding you may want to indeed check and make sure that you are not already using DFS-R. Jump into a command prompt and type in this command:

Dfsrmig /GetGlobalState

If the output is shown as “Current DFSR global state: ‘Eliminated’” then you are already using DFS-R and there is no need to go any further. Stop right here.

Gotcha’s

All Domain Controllers need to be online and available. If you have any redundant DCs listed and they have not been cleaned up (meta data an’ all!) then do so before starting this task

Depending on what Server OS and Service Pack Level you are on ALL DCs may need to be located in the default Domain Controllers OU. If they are located in a sub OU or elsewhere (for policy reasons usually) then consider moving them into the default location temporarily during the migration

The PDC Emulator MUST be online during the whole process – that’s the dude with the most up to date Policy and it is the DC that this whole process talks to the most

You need at least a Windows 2008 Functional Level for your Domain, so get rid of those soon to be end of life Server 2003 R2 DCs first

4 Steps to DFS-R

There are 4 steps to migrate from FRS to DFS-R using the Dfsrmig command:

Health Check: Run the following commands to check the health of current replication

Ensure there is enough free disk space on each Domain Controller for the migration

Run repadmin /replsummary to ensure current replication is healthy, resolve any issues

Run repadmin /showrepl * /csv > replication.txt to ensure current replication is healthy, resolve any issues in the output file

Migrate to Prepared State: Use the command Dfsrmig /SetGlobalState 1 to begin the migration, use Dfsrmig /GetMigrationState to check the current status of this step. Do NOT proceed until this step is complete

Migrate to Redirected State: Use the command Dfsrmig /SetGlobalState 2 for this second step, use Dfsrmig /GetMigrationState to check the current status of this step. Do NOT proceed until this step is complete. If you wish to stay with FRS for SYSVOL replication then stop here.

Migrate to Eliminated State: [NOTE:There is no going back after this step! You have been warned] Use the command Dfsrmig /SetGlobalState 3 for this final step, use Dfsrmig /GetMigrationState to check the current status of this step. Once this step is complete so is the migration.

That’s all there is too it. Honest.

If you did execute Step 4 in error, then as I said there is no going back. Ever. Except of course unless you rebuild the whole domain (a whole lot of fun for you then!).

Background

Following on from my earlier post about the death knell for Server 2003 which is due to retire in July 2015 I provide some guidance on uplifting your Domain Controllers to either 2008 or more relevant to this post, to 2012 R2. It has been a year since 2012 R2 was released in October 2013 so you better be ready for it…are you ready, are you sure? …go on be honest, does it scare you? Change usually does. This guide will serve as a calming oasis in a sea of chaos.

To clarify at the outset, we are not bothered about upgrading member servers here, that’s a big task for even smaller organisations as any legacy services and applications running on these will need some level of remediation to work on 2012 or 2012 R2 member servers. Heck, just migrate to the latest version straight into the ‘cloud’ as a hosted solution and let the 3rd party vendor do all the hard work (then all you need is a Trust or Federation! Easy!). Just remember that member servers on an OS of 2003 Server or above will function completely fine in a pure 100% 2012 R2 AD environment (but don’t forgot about July 2015!).

Out with the old…

NOTE: Also we are not talking about an AD migration here, this is a DIY guide to replacing all your flavour of the month Domain Controllers (Windows 2003, 2003R2, 2008 or 2008 R2) with all new shiny 2012 R2 Domain Controllers (DCs) – and then optionally uplifting your Domain &/or Forest Functional levels.

#Housekeeping

Please Please Please Please Please do some housekeeping. Clean up those stale objects (users, groups, computers, GPOs, Fwd and Rvrse DNS entries, SIDs, OUs, Sites, Trusts), clean down those global groups and lock down the number of people with privileged access. Your Security Chief (mean scary person) will thank you and your attack surface will be reduced accordingly. Honest.

Service and Application accounts in your AD often have more privileges than they actually need, they are usually classified as ‘stale objects’ as they probably haven’t been interacted with for quite a while. Identify the owners of these accounts, this is quite important as more often than not an application failure can be traced to the service account…but if you don’t know who owns/manages it the TTF is lengthened significantly.

Also use this time to document your AD structure and settings, seriously a lot organisations either 1) have no such document or even a visio diagram or 2) have the original one created as a vanilla ‘design’ back in the day but it was never updated since! Wuh? You mean you’ve actually got 30 DCs and not just 3 like it says here?!!!

Audit: The servers themselves and the Environment

Are your existing physical servers fit for purpose and can they support Windows Server 2012 R2? For your server hardware do the associated 2012 version drivers exist? Consider using virtualisation as DCs in virtual environments are fully supported (Hyper-V and VMware);

Will your AD be upgraded either 1. remotely by an in-place upgrade from Server 2003/2008 to Server 2012 R2 or 2. rebuilt from scratch 3. New hardware and built from scratch?

Cross architecture (32 bit to 64 bit) and cross language (change in server language) in-place upgrades are not possible, these servers will need to be rebuilt;

If servers are running a 64 bit edition of Server 2008 or 2008 R2 they can be upgraded to 2012 R2

If servers are running ANY edition of Server 2003 they will have to be rebuilt or replaced

Windows Standard editions will be upgraded to Windows Standard and Windows Enterprise editions will be upgraded to Windows Enterprise;

What is the size of your existing NTDS.DIT? This is important as your upgraded or newly built server MUST have sufficient memory to hold the entire NTDS.DIT file in active memory, in RAM. If your NTDS.DIT is 500MB, than your available RAM after all other considerations must be minimum 500MB – ideally more;

Note down your AD Schema version, go to a Domain Controller, run regedit and navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Parameters;

Non Windows clients, identify them and understand how they interact with and access domain resources, sometimes they have IPs or even Hostnames hard coded somewhere within their settings. Identify and either rectify or have a plan of action;

Network equipment that may need DNS information, check your switches, routers and firewalls and liaise with the network operators to understand the dependencies;

3rd Party applications, find out what if any dependency they have on AD DS and what may happen to functionality and service in the event of an upgrade. This means engaging with the 3rd party and having a plan just in case;

Services, applications or hardware (Printers, Multifunction Devices, Logging services, Proxy/RAS/VPN Servers, IP Cameras, NAS servers, SAN storage) that relies upon Active Directory and in particular Kerberos for authentication should be logged and if needed a remedial plan of action formulated;

Upgrades and rebuilds of DCs should be completed out of hours where possible;

Identify your current FSMO role holders > netdom query FSMO;

Note down your Domain and Forest Functional levels;

To be honest a lot of you will need new server hardware or new VMs, so you will be introducing 2012 R2 side by side with the existing servers. Makes it a lot easier than attempting to in-place upgrade the OS, which isn’t possible in some cases e.g. x32 and x64 2003/2003 R2 Servers CANNOT be OS upgraded to x64 2012 R2 directly.

Testing – you do have a Non Production environment, right?

Most of you won’t. Tough ask then, to make changes in Live. Well, try to mock up some kind of non-prod environment and make it as life like as possible – then try some testing. However such a vanilla environment won’t reflect reality so prepare for the worst and have a clear roll back plan.

Gotcha’s:

Updates to locally installed application services for monitoring or optimisation – make sure the product you use for monitoring/optimisation has a 2012 compatible version/pack available for example SCOM, Nagios, Foglight

Applications will fail to authenticate and will require remediation – some services running elsewhere in your organisation may fail to authenticate or work once you introduce 2012 R2 Domain Controllers or when you switch off all the legacy 2003 or 2008 ones. Plan for this.

Check for hardcoded host name usage – I’ve seen many organisations throughout the transitions and migrations I have completed where 3rd party services/applications are provided the hostname or IP address of specific DC’s in order to function. When these DC’s are no longer DC’s the application or service simply fails to function as before.

When you come to demote the old DCs do not accidentally tick the box “This is the last Domain Controller in the Domain” cos if you do then you’re in a whole heap of doo-dah. If that happens, please don’t call me. Pretty please.

File Replication Services (FRS) is fully depreciated in Server 2012 R2 so you better be rid of it prior to uplifting. The replacement is DFS Replication, see my brief guide HERE on how to do this.

What Will or Might break…

This list is by no means comprehensive but should give you some idea of what you need to watch out for:

DNS – no internal or external DNS resolution. In other words you won’t be able to check if Murray is losing (again!)

DHCP – clients drop of like lemmings of a cliff (oh how i loved that game!)

Printers – users love to print. They get angry when they cannot. I’m a user too, I get ANGRY when i cannot print my Marvel superhero pics

Network Devices – network stuff, that dark art of magicy wizardly stuff. Make sure a wizard is at hand to fix stuff

The actual Process…how to Uplift to 2012 R2

Finally, what you actually came here to read. Phew, after all that nonsense upstairs. This is HOW and WHAT you need to do:

1. Get Change Approval and engage with all key stakeholders (CTO, CIO, IT Consultants/Architects, Senior Management, Application owners, Service Line Managers etc.). As stated before, finding out who application and service owners are is critical, both to engage them and keep them informed of the process.

2. Have a Roll Back plan, a method that states the steps to get back to before the next step i.e. as if you never started this.

3. Ensure good and verified backups of existing DCs have been taken, verify any offsite backups and ensure they can be restored without errors if needed

5. Add in all new servers with 2012 R2 installed that you may need. Join to your existing Domain as Domain members. Let then just chill out, before battle commences for takeover

6. Jump onto one of the new 2012 R2 servers. Add the AD DS Server Role, this will run AD Prep > SCHEMA Update (the bit that scares you all) > Domain Prep and part of that process is adding this as a new DC. After the update check your AD Schema version, go to a Domain Controller, run regedit and navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Parameters

2012 R2 Server Manager

7. Add in some DNS Role servers and allow DNS to replicate (your network has DNS as AD integrated right?! IF using BIND or other DNS Service then you have more work to do in your planning and testing stages)

8. Check that your newly introduced 2012 DCs are fully replicating, use REPLMON and check the event log for errors. In fact check both the System and Application event logs and filter for Warning, Critical, Error events.

9. Test your Apps and Services while 2012 R2 Domain Controllers are running at same time as your old ones

10. If you built new servers then transfer FSMO roles > Move-ADDirectoryServerOperationMasterRole -MyNewServer “Old Role Holder” -OperationMasterRole 0,1,2,3,4

11. Migrate any other roles and services running on existing DCs e.g. DNS, DHCP, CS, AD RMS to new DCs

12. Close down all ‘legacy’ Domain Controllers in a phased approach, always watching for service failures anywhere across your environments. It’s useful to make your Helpdesk aware and to relay any unusual incidents through to you on the Day After the Night Before

13. Pat yourself on the back, it all works nicely. Good job.

Server 2012 – Hurrah!

All these steps can either take an evening or many months to complete. That depends on the size and complexity of your infrastructure.

Supportability

No good using 2012 R2 if your nice support engineers don’t know PowerShell. Teach them, send them to a course or call me for some quick-fire lessons!

If you spot any errors, have any suggestions, tips or improvements please comment to let me know.

Always in a state of transition, IT departments around the world are continually deploying new systems, applications and hardware. However one of the biggest changes, and challenges, is the successful migration from an existing infrastructure to a whole shiny new one with all the bells and whistles it comes with.

Let me quickly introduce myself, I’m Zulf and I currently work for Fujitsu as a Solution/Technical Architect mostly on migrations with a particular focus on Active Directory, Exchange and SharePoint.

Preparation, preparation, preparation! That there is my mantra, the first word that comes out of me when looking at any migration. It really doesn’t matter whether the migration is large or small, preparation is key and I’ll tell you why.

Without it you will undoubtedly fail, or if you to manage to somehow struggle through, the stress and strains upon the shoulders of those tasked with the migration will lead them to breaking point. I can truly say I have “been there, done that”, I worked on one of the biggest migrations in the UK – 125,000 seats over a 30 month period – yet the migration of the data (filestore and email) was treated as a minor irritation by the project planners as it was deemed straightforward – copy and paste anyone?

The result? An inefficient, trouble strewn, terrible state of affairs that ended up using more resources than it needed, took twice as long as it should and resulting in levels of stress and anger never before seen in the user environment. The ‘planning’ time set aside for this monumentous migration task (which spanned the whole UK) was a truly dismal 6 weeks.

Understand what you want to do: What are you trying to achieve? What are your outcomes, timeframe and budget. Your timeframe? Double it now!

Understand how you are going to do it: Identify the tools, resources, expertise and finances needed to effect your change.

Prepare: Lay the groundwork, communicate with the affected parties and create a plan of action in your chosen project methodology. Be realistic with your timelines.

Prepare again: Purchase the products and tools you need, book in the resources and ensure the right equipment and tools are available and accessible.

Prepare once more: Prepare for the unknown. Yes, that’s right – prepare for something you’re not even aware of yet. How? Purposely set aside delays in your project (catch-up days, firebreaks) for the infamous Rumsfeld ‘unknown unknowns’ – use them if you need them, finish up early if you don’t.

Pilot: Once you’ve got what you need find a sample (whether it is users, computers, servers etc. etc.) and run through a mini version of your end to end migration. Yup, the whole thing from start to finish – in some cases you may not be able to go the whole way, but if that means you have to pilot a further change at a later time DO SO!

Deploy & Migrate: Finally that point when you can approach a migration with confidence

If you are indeed planning or going through a migration and need assistance get in touch with me here at my Blog and you can be assured that a friendly and experienced consultant (me!) will respond.

Too often an organisation changes only when forced to, either by policy, necessity (end of life, end of support) or organisational change. It is always best to change when you have the control, so be proactive, look at what’s coming over the horizon and act quickly.

Depending on when you are reading this Windows 2003 is either still in your environment or it’s already gone.

However you look at it, this has been the reliable & trusted workhorse of the Data Centre (Comms room or Broom cupboard aka ‘it’s under Matts desk!”) for the last many years and incidentally mostly in x32. From Exchange to SharePoint to SCOM/SCCM and a whole plethora of business apps and services Windows 2003 Server has been the main man for such a long time we take it for granted.

It is now time to say goodbye 😐 , mainstream support ends July 14th. 2015. That’s LESS than a year. No more patches, updates. Nothing. Only those who are desperate or really stupid will keep any live services running on them beyond 2015 The security risk is just too great.

‘What to do?’ I hear you cry, well consider this:

Migrate upwards and onwards to 2008R2, 2012 or even 2012R2, does your app/service vendor support this, your hardware/virtual platform?

Migrate to a service based model where your solution is now cloud based, again is there a viable solution for your app/service?

Migrate to a whole new app/service with all the pain that comes along with that, but at least you can hop straight to 2012/2012 R2 (hopefully)

There is a LOT of work to do, and currently I do not see many organisations doing that work. Perhaps after budgets are being signed off in the 2nd Quarter 2015 the panic might start.

The Great Server 2003 rundown brings an end to an era, it really was the NetWare killer (although the ball got rolling with AD in 2000 Server) providing the knockout blow. It came with a fully blown Mail service (free!), a free Web Server (IIS 6), the awesome GPMC and even WSS to host SharePoint sites (free!). It was resilient. It was brilliant. Its time has come.

Like this:

As usual during a data centre migration at some point you need to move a huge chunk of data. I’ve come across several of these challenges in my years of migration and I usually end up with using the two most reliable yet simplest tools in my ‘migration toolkit’. Robocopyand SubInACL. Of course you have icacls within PowerShell and some of the more recent Windows Server versions, but the oldies are still goodies even in 2014.

The raw copy is the easy bit, just robocopy files from Old Device to New Device using the LAN, WAN or whatever you have at your disposal. If you wish or need to use an interim device for quicker transfer then do so, whether a NAS device or Eclypt drives – just make sure they are encrypted in case of loss during transfer.

Oh just a polite notice, for me Folder=Directory, Directory=Folder – same thing, different word.

So you’ve got the raw data across. Now those pesky NTFS permissions are still needed. 2 ways this can go down, the New Device is either:

In the same domain as the Old Device

Or in a different domain to the Old Device

If in the same domain, full steam ahead and rush along to the next paragraph. However if it is a different domain between the Old and New devices then you need a Trust in place. Minimum one-way from Old < New (Old Trusts New domain). If you cannot use the trust, then you better hope you have somehow migrated SIDHistory across to your domain user objects OR you are using the same group/user names in the New Domain as you were in the Old domain OR you are able to create a mapping file between the two(!). Did I not tell you it can get quite complex?

Record the Permissions

Full steam ahead here, go to the Old Device. Identify a Folder whose NTFS permissions you would just love to capture and need to re-apply. Type in the following command at a command prompt (ensure you have the subinacl.exe file handy):

The /output switch lets you specify where the NTFS dump file listing all the ACLs will be errrr….dumped(!) This can be anywhere, I’ve just put it in the root of C: in my simple example. I also gave mine an apt and descriptive filename. Just in case I have cause to come back to this file in a few weeks, calling it commandfile.txt just doesn’t help.

/subdirectories is an interesting beast, if you leave it as is, it will capture all NTFS permissions for both FOLDERS and FILES (largest output file size) but changing it to one of the magically delightful options below does something very different:

The last bit H:\ThisIsTheOldDeviceFolder has to be the directory/folder whose permissions you need to record.

Once you let the command loose, it creates a file called DumpMyOutputFileHerePlease.txt and this file could be huuuuuuge! Zip it for transport. If it’s too big to Zip then split it using a nifty tool like GSplit.

Replay the Permissions

Now you need to copy that file somewhere, anywhere where you can easily see the New Device copied raw data for example I used C:\Temp.

Run the following SubInACL command to replay the permissions:

subinacl/playfileC:\Temp\DumpMyOutputFileHerePlease.txt

Now, remember this tidbit of highly useful information. Running this command to replay the NTFS permissions makes one HUGE ASSUMPTION. It assumes that on the New Device you are using the SAME DRIVE LETTER and top level FOLDER as you had on the Old Device.

Heck what if you have done a bit of transformation on your New Device and re-organised the data and top level folder structure. Hopefully you’re just using a different drive letter and maybe just a different top level folder. If that is the case then you need to do 2 things before replaying the permissions.

Open the file DumpMyOutputFileHerePlease.txt

Change every line containing this “H:\ThisIsTheOldDeviceFolder” to whatever it needs to be to match your different drive letter or path e.g. “S:\WeNowUseThisNewFolder” use Find/Replace to seep that up. SAVE the file. You must SAVE it. Replace or Save as New, as long as you SAVE it please.

Once saved just run the exact same command (except now your .txt file has been modified):

Like this:

Posts navigation

About

Zulfs blog where you'll find bits of random info on tech, cars, trading and religion. All mashed up MongoDB style! Just to be very CLEAR all opinions are my own personal viewpoints and should not be taken as gospel without verification. Happy Kindling.

Blogroll

About

Zulfs blog where you'll find bits of random info on tech, cars, trading and religion. All mashed up MongoDB style! Just to be very CLEAR all opinions are my own personal viewpoints and should not be taken as gospel without verification. Happy Kindling.