If it is an extremely busy (and extremely huge) database, 100GB of logs per week may not be outrageous. Without more information on database size, transaction volume, record sizes, etc., that is difficult for us to judge.
The more important question is: if this database is being backed up each night, why aren't the logs getting pruned? Normally, one doesn't need to worry about transaction log volume per week.
- On a properly configured MSSQL server, the transaction logs are physically separated from the data: they reside not only on a separate volume, but on a completely separate RAID array.
- If the database (or the physical volume that stores the database) is lost, you can restore from the most recent backup and then replay the transaction logs to recover data until the moment that the failure occurred.
- Any transaction log entries created before your most recent backup can be pruned from the LDF file. Usually, the logs themselves get backed up before they get pruned; this maintains the possibility of recovering to arbitrary points in time that may be prior to the most recent backup, if older backups are retained.
So, here's the bigger question: how is this SQL server being backed up, and are the transaction logs being pruned at the time of each backup? Was there a nightly backup process that suddenly stopped working?
If the previous administrator was too lazy to use proper service accounts -- and this is not uncommon -- lots of things, including backups, might have stopped working when his/her account was disabled and the built-in domain administrator account password was changed.